If Arbellatra believes that the Imperium is straining under the stress of communication problems, she's already using the navy's couriers. So the original X-boats would have to beat 3.4 parsecs per week. Which is more than 2.6 parsecs/week.
In Arbellatra's time, Navy couriers were likely aligned with factions in the Civil War, and were probably not effective for long-distance, Imperium-wide communications. Placing the X-boat service in the hands of the IISS de-politicizes the main: unlike the Navy, the IISS doesn't have strong ties to any faction of nobility, and is more likely to be able to deliver the mail.
If you plan for a courier a day, the arriving courier beams the priority news to a waiting courier [...] The rest is transferred during the next 24 hours and is ready to go on the next courier. That slows your second class mail to your 3.4 parsecs per week, but the priority mail goes through at 3.9 (3.887) parsecs/week. Possibly a bit less due to jump variance, but I can't quite figure out how to compute that.
I'm not 100% sure how to compute that, either. Here's what I did:
For the single-ship courier run (the Type TJ case), it is fairly easy: over the length of the run, the jump variance will average out to 168 hours per jump. I figured an average of 24 hours in realspace between jumps to compute the effective average speed.
Any network where messages move from one or more inbound ships to a sorting center to one or more outbound ships is more complex. Because of jump variance, we don't know when we will get the next inbound ship. It should average out to 4 ships a day ... but we may well have a day where we get no inbound ships, followed by a day where we get 8, one right after the other. Thinking about the flow, then, I came up with a few principles:
- Ships need to be standing by, ready to leave when the message center releases them. This means that there need to be enough ships "in the pipeline" (getting fuel, maintenance, new crews, etc.) so that a ship will be ready to go when it is needed.
- The maintenance pipeline is designed to output a ship, ready to go, at specific intervals. If ships arrive faster than this due to jump variance, they will stack up in an input queue; if ships arrive more slowly, the input queue has to be big enough that it will not run dry in the meantime.
- It follows that we therefore cannot release a ship "early". Even if the ship is ready to go, releasing a ship early means that we will likely have to wait longer for the next ship to be ready from the maintenance pipeline.
- There is no point in releasing a ship if it has no messages to carry. For sake of argument, we will assume that there is always locally-originated messages ready to go out-system. Therefore, ships will never be released "late".
At this point, we have a process that is outputting ships to Jump out system at a regular rate. I call this the "dispatch rate", and measure it in hours per ship on a given link. Canonical materials tell us that the fastest dispatch rate for the X-boat system is 6 hours. Presumably there are other links with a slower dispatch rate.
Once this process is up and running, the arrival of inbound messages is an asynchronous event: messages will arrive at random points in the dispatch cycle. If the inbound ship arrives just barely in time for message processing, these messages a delay of (at minimum) whatever amount of time that it takes to transmit them to the message center, process them, and relay them to the outbound ship. I'll call this XmitTime. If the inbound ship just misses the outbound ship, messages will experience a delay of XmitTime+DispatchRate. If we assume that the inbound ship arrives are a essentially at random with respect to scheduled departures, this means that the average delay at each station is XmitTime + DispatchRate/2. I called this average delay "HandOff", and picked 6 hours more-or-less at random (it corresponds to a 1-hour XmitTime and an overall average dispatch rate of one ship per 9 hours, roughly 55% of the links on 6-hour dispatch, 35% on 12-hour, and 10% on 24-hour).
The problem seems to be with your 24 hour handoff time. That's what I'd calculate with for a lone courier doing the entire run on its own.
That's what I assumed "ordinary courier" to mean - a single ship making successive jumps as rapidly as possible, with no "pony express" hand-off to another ship.
What is your Navigational Efficiency?
It is just an alternate way of expressing the average distance per jump executed; I call it "navigational efficiency" because there may be many factors - locations of bases or stops, astrographic features, economic reasons, or other factors that may cause the ship to depart from a maximum-jump, straight-line course.
Over a 200-parsec straight-line route from origin to destination, a J-4 ship that reaches the destination in 50 jumps exactly has 100% navigational efficiency. No ship in the real world will hit this mark. I believe the highest reasonable numbers over a significant course to be in the mid to high 90's. For example:
- If the distance traveled is not an integer multiple of the ship's jump number, then navigational efficiency will be less than 100%. A J-4 ship over a 201-parsec course will operate at 98.5% navigational efficiency.
- If a J-4 ship has to make 51 jumps over a 200-parsec route (for example, to dogleg around a 6-parsec rift), the ship made 3.9215... parsecs per jump, or 98% navigational efficiency.
Navigational efficiency can be calculated from the observed jump performance (and predicted jump performance can be estimated from navigational efficiency):
Navigational Efficiency = Observed Average Parsecs per Jump / Ship Jump Capability
Expected Average Parsecs per Jump = Ship Jump Capability * Navigational Efficency
Between 1 and 24 hours (average 12½) would be what I would expect, bade on the assumption that high-population worlds would have enough potential passengers to maintain a regular daily schedule.
Assuming that the messages are electronically transferred and the XmitTime is the same as for the IISS, I get a 13 hour handoff time minimum.
Sure, the less populous worlds wouldn't be getting daily J4 passenger service. Below a certain population size they won't be getting any J4 passenger service.
These gaps have to be figured into any long-haul communications network. There are plenty of locations where high-population worlds are more than 4 parsecs from the nearest other high-population world. When there's no J-4 passenger service, do the messages stop? Do the transfer to a J-1 subsidized merchant, or a J-2 far trader? How frequent is service across these gaps, and how long are the gaps?
Since Traveller population levels are also determined at random, networks of high-population worlds are essentially random. The canonical OTU X-boat links are probably also randomly generated, based on starport type. Fundamentally both types of networks are random, and should perform about the same for long-haul.
I agree with you that basing the network on population (rather than just starport type) is probably more useful, since such networks will tend to tie population centers together. It is worth noting that in T5, Marc agrees with you, since the new method for determining X-boat links is to use both starport type and population (and bases).
