Consolidation Thread: Xboats in a System

[robject]

This was discussed years ago, but I'm re-opening it since I don't remember the range of conclusions.

GIVENS

* The benefit of a fully-realized Xboat system is its reliability. - Walt Smith, 1998.


CT Traders & Gunboats, pages 8-10.

(p8) it jumps, relays its messages to the station on arrival, and then waits to be picked up by a tender, to be refuelled and sent on its way with a new load of messages. The local station, meanwhile, accepts messages, encodes them, and transmits them to a tender at the edges of the stellar system. Messages brought by the arriving xboat and intended for further down the line are consolidated with then ew data and all are sent on to another xboat already fuelled and standing ready to leave. The entire network operates like the pony express - messages are always moving at top speed. Transfer time for messages from one xboat to another can beas short as ten minutes, and is rarely more than an hour.

(p10) High population and high technology star systems can be expected to have up to twelve xboats presentat one time, probably distributed evenly between arriving and departing ships.

(p10) The express boat is also capable of only limited endurance. While it can sustainits crew of one and a passenger for the week it spends in jump space, its power, atmosphere, and food reserves are good for only about three days after break-out.

ASSUMPTIONS

• (T+0 hours) it arrives very close to an Express Boat Tender.
• (T+0) relays its messages to the station,
• (T+0) and then waits
• (up to 8 hours/ <2 million km?) to be picked up by the tender
• (1 hour) to be refuelled (incl. life support and crew change)
• (less than an hour) and sent on its way with a new load of messages.

The local station, meanwhile:

• (T+0) accepts messages, encodes them, and transmits them to a tender at the edges of the stellar system. Messages brought by the arriving xboat and intended for further down the line are consolidated with the new data and all are
• (T+10 to 60 minutes) sent on to another xboat already fuelled and standing ready to leave.

CONCLUSIONS

• The Xboat is capable of very targeted jumps, landing within a short travel radius of an Express Boat Tender.
• The Express Tenders are necessarily highly reliable; you know exactly where they will be.
• Thus, delay is entirely dependent on recovery time.

THE MAXIMUM RANGE IS 24 HOURS AWAY (with turnaround)

That is the farthest range that permits 12 Xboats to be present at any one time. One day there... and a REPLACEMENT tender arrives at the old rendezvous point. That's a maximum range of 0.1 AU (9 million km) --- in other words, Xboats are very good jumpers and Express Boat Stations are ON STATION.

This also allows a station to carry a replacement Xboat in case there's a problem with the incoming one. With room to spare.

"TWELVE XBOATS AT ANY ONE TIME"

Total throughput seems to depend entirely on the turnaround time. An eight-hour total turnaround time would mean twelve Xboats turnaround every eight hours, implying a total of 12 x 3 = 36 Xboats arriving and leaving daily, with 12 insystem at any one time.

 

[mike wightman]

I think the majority of people underestimate just how many xboats the Imperium actually has...

just remember that according to S:7 they can operate without a crew...

The xboat is a jump robot

 

[Spinward Flow]

So, transmission time is NOT AN ISSUE... TYPICALLY.

This is where we get into the Pony Express™ implementation of what amounts to an interstellar evolution of TCP/IP (Transmission Control Protocol/Interstellar Protocol).

Something that has always been glossed over (pretty mightily, at times ) is ... just how much data can an XBoat transfer ... and how long does it take? In other words, what's the I/O speed for data transmissions? Answer, never specified in publication.

The closest answer we get is the "under seven minutes" citation ... but the circumstances of that "under seven minutes" isn't fleshed out with useful operational details, such as whether that particular (record) instance was essentially "choreographed and staged" or otherwise differed from "normal operations" in any way.

I can easily imagine a circumstance in which an XBoat is prepositioned ready to jump as soon as possible after receiving a relay from an inbound XBoat ... just to break the record. Typical procedures aren't followed in order to enable the FASTEST possible turnaround time. Net result ... under seven minutes from breakout to dispatch. However, in order to achieve that record, a few ... corners ... had to be cut:

• The arriving XBoat hadn't even finished transmitting their entire data load to the Tender.
• As soon as the FIRST complete record bound for the destination was linked through the Tender and transmitted to the outbound XBoat, the outbound XBoat immediately got ready to jump, leaving all other communications bound for the destination "on hold" for the NEXT XBoat to be dispatched.
• The receive, uplink, jump cycle took less than seven minutes to complete a highly orchestrated and staged "test" that does not represent standard operational practices, but which did manage to break (and hold) the record for fastest turnaround time between breakout and jump, carrying information from source, through the intermediate system, to the destination (which is all that mattered for breaking the record).
• If the inbound XBoat is coming from an "end of the line" backwater world with VERY LITTLE outbound communication traffic (so not much data to transmit after breakout) the staging of this record breaking attempt would be even easier.

When you "change the conditions of the test" ... you can achieve results that ought to have been impossible.
And then when you "publicize" that the record has been broken, but not how it was done ... ... people (predictably) leap to the WRONG assumptions (with confidence!) and believe that your Express Network system is far more capable than it actually is.

BUT ALSO NOTE that the time between jumps always seems on the order of an hour or two (e.g. more than seven minutes, less than 4 hours); this is probably a reflection on general flight readiness.

There's ... a problem ... with this interpretation.
That problem is logistical ... how fast a Tender can "turn around" an XBoat for dispatch.

Let's look at it from the point of view of an individual XBoat on the network, first.

1. An XBoat breaks out of jump and IMMEDIATELY begins transmitting a firehose of datastream to the nearest Express Tender.
   • How long of a duration that takes is never specified.
2. While the inbound XBoat is transmitting, a Tender needs to maneuver (because XBoats have no maneuver drives themselves) to dock with and retrieve the inbound XBoat.
3. Once the inbound XBoat has been docked with, it needs to be moved into the hangar bay of the Express Tender.
4. Engineering crew onboard the Express Tender oversee the 16 hours of required, routine maintenance checks performed on jump drives after every jump (the pilot would NOT be considered "qualified" to do this work).
5. After 16 hours of continuous refresh/refurbish/replenishment in the Express Tender's hangar bay, the XBoat has been fully fueled and is ready for deployment.
6. The Tender has maneuvered into a position to undock from the (now outbound) XBoat, outside of any 100D jump shadows that could intercept the anticipated jump trajectory.
7. The outbound XBoat undocks and the Tender maneuvers away (removing the Tender's 100D jump shadow from the list of navigation hazards).
8. The outbound XBoat remains on station, awaiting the completion of an uplink of data and order for dispatch from the Express Tender.
9. Data update transmission from Express Tender to outbound XBoat terminate and a dispatch authorization is given by the Express Tender.
10. The outbound XBoat jumps to a new destination star system.

Turn that around and look at it from a Tender's point of view.
How many XBoats can 1 Express Tender "attend to" at a time, concurrently?

Well, according to the deck plans published in LBB S7 ... 2x XBoats with the hangar bay doors closed (because of dimensions and packing efficiency) ... 4x XBoats with the doors left open (maybe 5x XBoats if you get REALLY creative playing TETRIS).

If we assume that 1 Tender = 2 XBoats being replenished concurrently (with some staggering of the schedule for occupation of the hangar bay), that would mean that a single Tender can manage the recovery, maintenance/replenishment, deployment of 1x XBoat every ~8-10 hours getting cycled through the hangar bay.

It would also be possible for an Express Tender to "dock" with an XBoat using only the Tender's Fuel Probe, refuel an XBoat without bringing the XBoat into the hangar bay and then undock to maneuver away in less than 1 hour (basically, 2 combat rounds = 40 minutes) for a minimum "no maintenance cycle" turnaround time of less than 1 hour for a specific XBoat.

The problem with "no routine maintenance" after jumping is that's the kind of Technical Debt that can build up over time, if it keeps happening (too many times in a row). So the XBoats are going to need to "cycle through the hangar" on the regular after a (limit defined by regulations) certain number of jumps. For simplicity, I'm thinking that 3 jumps "no maintenance after jump" would require a "routine hangar maintenance" cycle before making the 4th jump. This would effectively increase the number of XBoats that can be refueled and dispatched by a single Express Tender on a daily basis. It would certainly help bring down the "maximum wait time" between inbound and outbound to the "less than 4 hours" standard for keeping data moving along the Express Network.

But at that point, you're starting to talk about dispatching 6-8 XBoats per 24 hour "day" per Express Tender.
At 40 tons of jump fuel required (because LBB2.77 drives which don't have jump governors!) per outbound dispatch, that then turns into a fuel transfer rate of 240-320 tons of fuel per 24 hours just to get the XBoats to jump! Problem is, LBB S7 Express Tenders only have 150 tons of fuel onboard!

And that's a problem ... ... because LBB S7 Express Tenders only have 1G maneuver drives and gas giants tend to have "large" 100D radius jump shadow limits. Maneuvering down+up the gravity well of a gas giant could easily take 24 hours, round trip, during which the Express Tender is NOT ON STATION and is unavailable to retrieve, refuel and deploy any XBoats (since the Express Tender is maneuvering inside the jump shadow gravity well to refuel itself).

So after fueling up 3x XBoats for dispatch, a LBB S7 Express Tender is going to have to enter a jump shadow to refuel itself.

The alternative to sending the Express Tender "down the well" to get fuel from a gas giant would be to "bucket brigade" fuel shuttle services via Scout/Couriers (which have 2G drives and can make the round trip faster!).

Assuming a 320 ton "worst case" fuel demand per day, Scout/Couriers (plural) would need to make 9 fuel shuttle deliveries (of 36 tons each, leaving enough for the Scout/Courier to continue maneuvering) in a single 24 hour time span ... just so that 1x Express Tender can remain on station outside the jump shadow, ready and able to retrieve, refuel (and maintain/refurbish) and dispatch up to 8 XBoats within a single 24 hour window.

In other words, the LOGISTICS of keeping all of those plates spinning is QUITE the undertaking!

 

[whartung]

• The Xboat is capable of very targeted jumps, landing within a short travel radius of an Express Boat Tender.
• The Express Tenders are necessarily highly reliable; you know exactly where they will be.
• Thus, delay is entirely dependent on recovery time.

The Express "station" (there must be an express station, the tenders alone cannot do the job) is in solar orbit, and, likely, trailing (or leading) the main world. Close, but not too close, So it's position is always well known.

The XBoat jump is no different from anyone else jump. 168 hours +/- 10%. At Earth orbital velocity (30km/s), thats a 1.8Mkm radius assuming it's "aimed" at the now + 7 days location of the express station. Not a big deal. Since most messaging is transmitted, recovery time isn't critical, it's just helpful. At 1G, 1.8MKm is a 15hr round trip. If you launch an XBoat every 6 hours, you'll need 3 1G tenders to keep up with that traffic (probably at least one more when the boats start clustering).

Outside of specific circumstances, such as planets deep in solar (or gas giant) 100D, causing jump masking, there's no reason to play games with XBoat vectors (i.e. tender accelerating them to destination specific vectors). The destination tenders job is to "catch" the XBoat and make it heave too. That said, there's never really a good reason for a XBoat waypoint to be in a jump masked area.

XBoat jump on a schedule. Planners like schedules, thats how they know when things are due and when they're late. There may be exigent circumstances to require an immediate jump, but its rare. The 32 jump arrival windows messes with all sorts of schedules.

If you sent an XBoat every hour, it's very likely they will arrive out of order. But there's no control over that.

When help is always 2 weeks away, a few hours here or there don't really matter than much.

With XBoats on a schedule, they're much easier to provision. No need to "wait for the next one", we have the 6am boat ready to go. The XBoat station is where the extra XBoats are parked. A surplus is maintained, anything above that is shipped someplace appropriate. There's always slack in the system, when a boat can be 32 hours "late", you got to over provision a bit to prevent stalls in the network. Also makes it much easier to take one out for maintenance as necessary, including maintenance on tenders (all sorts of fun when you're short a tender for week...).

 

[Spinward Flow]

The Express "station" (there must be an express station, the tenders alone cannot do the job)

I've always viewed the Express Tenders as merely one of the links in the chain, rather than the anchor points that the entire endeavor rests upon. What you refer to as a "station" I think of as being a Scout Base (somewhere, in the star system).

When LBB S7 was written (and the Express Tender deck plans formulated), the Express Tender design detailed in that book "seemed reasonable" and there wasn't a good reason to question a lot of the assumptions underpinning it. But in hindsight, there are some details of the Express Tender design parameters that probably ought to be subjected to a refresh (and redesign).

Things like ... how is a 1000 ton J1/1G starship supposed to self-deploy across a 4 parsec gap in the Express Network when it only carries 150 tons of internal fuel? If it can't it's going to have to be build "in-situ" at every world along the Express Network ... which isn't always going to be a reasonable proposition.

It's logistical details like that which have me thinking that if you LBB2.81 standard drives a redesign, still using H/H/H drives (like the original) that it would probably make the most sense to (re)design Express Tenders as 720 ton J2/2G starships, except unstreamlined (LBB5.80 configuration: 7), with internal and external docking capacity (880 tons worth @ J1/1G) which would be capable of hosting up to 800 tons of big craft (which means, essentially up to 8x 100 ton XBoats and/or Scout/Couriers simultaneously) at reduced drive performance. Have a "more modest" internal hangar bay (probably 220 tons for 2x 100 ton big craft) and a larger fuel fraction (to fuel more XBoat dispatches before running out of fuel). Include small craft fighters (and crews) which can do the "legwork" of retrieving and deploying XBoats to minimize the amount of maneuvering that the Express Tender needs to do itself while coordinating with the small craft, allowing the Express Tender to focus more on data communications and station keeping/maintenance work on XBoats.

Same role, but with updated details to better "suit" the mission profile with better logistical support built into the design.
A sort of "do one better" effort, if you will ... while still remaining TL=A for everything.

 

[robject]

Thank you Whartung. I've been reviewing other threads here and I think you've got it.

ref

P

Thread 'How many Xboats?'

Aug 8, 2002

How many Xboats/Xboat tenders does it take to maintain a Xboat route?

• plop101
• Replies: 14
• Forum: Imperial Interstellar Scout Service

 

[robject]

I do wonder if it would help if Xboat jump drives are tuned to high-naval quality. I'll dig through High Guard and see what that is.

Ahhh it's in Traveller5... but it SHOULD be somewhere in CT or MT, since Marc's _Agent of the Imperium_ assumes that navy ships tune themselves to some degree.

T5 Book 2 p112

Constant Time. Time in Jump Space is independent of distance. A ship entering Jump Space remains there for a constant length of time, typically a week (168 hours, plus or minus 10%). A ship in JumpSpace-1 travels about one parsec in about a week. A ship in Jump Space-2 travels about two parsecs in about a week.

The actual time naturally varies: commercial ships expect a variation of Flux * 2 hours; finely tuned jump drives(naval) expect a variation of Flux * 1 hour.

^
That's -5 to +5 hours, by the way, so 163 to 173 hours. Still lots of slop time though.

_Agent_ seems to allow better tuning. But then, that's BCS, and Traveller5's core books only directly deal with ACS.

 

[mike wightman]

I think it is in a MT DGP Q&A with regards to fleet jumps...

 

[whartung]

I think the majority of people underestimate just how many xboats the Imperium actually has...

If you have a 6 hour XBoat schedule (4x a day), you need 31 XBoats per route partner. You need 7x4 just to handle the jump lag, and you need some extra to cover the Jump arrival window and XBoat recovery.

Regina subsector alone has 7 XBoat routes, and you need to double that (one for each way).

So, that's 14 x 31 = 434 XBoats, just for Regina. For the Spinward Marches, the number is over 5600. Thats just to satisfy base traffic, you need more to handle maintenance and outages and such.

 

[robject]

Per Walt Smith, the Xboat network is designed for reliability. That sounds right to me.

 

[robject]

Per Dan "Far Trader" Burns:

...if you have more than two incoming links you have to wait for all of them to arrive before dispatching any of your readied X-boats so they can catch the through x-mail for their respective link.

This is a potential problem, although you could always just mandate return trips being synchronized, rather than ALL ROUTES IN synchronization. It's more doable. It's certainly lazier and still reliable.

 

[Condottiere]

I think it's least cost.

Reliability being more a question of statistics.

 

[robject]

Probably Closer to the Original Concept

Say you have an Xboat Tender at Regina, and it has two Xboats.
Then you have an Xboat Tender at Hefry, also with two Xboats.

XT1: Sends Xb1 to Hefry.
(+1 week) Xb1 arrives at Hefry. One hour later, Xb2 is sent back to Regina.
(+2 weeks) Xb2 arrives at Regina. One hour later, Xb3 is sent back to Hefry.
(+3 weeks) Xb3 arrives at Hefry. One hour later, Xb1 is sent back to Regina.

And so on. Xb4 is held in reserve, just in case. Perhaps the tender in Regina has a spare as well.

Replicate for all links.

Thus if you have, say, four legs converging on Glisten, you're likely to have something close to 12 Xboats in system.

Although the original booklet suggested population and TL plays a part in the number of Xboats, but this is a dependent network so I'm not sure how that can be accurate.

---