igb@Fulcrum.BT.CO.UK (Ian G Batten) (06/07/89)
Thanks to this group, my Trailblazer is now working perfectly. But I have to explain to my management how it works. Does anyone have either a description (ideal) or pointer to a description of how it works? I've already found that uucp transfers in UUCP mode (S111=30) are about SIX times faster than without, so there's obviously some hairy stuff going on. ian -- Ian G Batten, BT Fulcrum - igb@fulcrum.bt.co.uk - ...!uunet!ukc!fulcrum!igb
mcp@ziebmef.uucp (Marc Plumb) (06/15/89)
(BTW, in response to someone's earlier discussion, V.32 is 4bits/baud at 2400 baud.) "What is a trailblazer" seems to be a common question, so I'll post... A Trailblazer (TM of Telebit, probably) is a really nice modem. It does all the 300/1200/2400 baud stuff, but it also has a proprietary scheme called PEP (Packetised Ensemble Protocol) that is the interesting part. The modem is quite bright, and all data sent through PEP is CRC-checked and whatnot, so the modem handles most errors. At the lowest level, PEP is a half-duplex (i.e. one direction at a time) protocol that divides the 0-4kHz band into 511 or 512 (I'm never clear exactly which) 7.14 Hz channels, and sends 0, 2, 4, or 6 bits across each channel at about 7 Hz. This results in bloody enormous bandwidth, and (compared to other modems), bloody enormous latency. The modem monitors the line quality on each of the channels and decides how many bits to try and push through it, so it can fall back in very fine incrememts - I think it's 50 bps. I believe raw bandwidth over a pretty-much-ideal phone line comes to 18.8 kbps, with some loss due to checksum overhead and phone line quality. Heavy telecommunications types love the fine fallback and pig-headed persistence of the protocol, becasue it can cope, gracefully, with absolutely abominable phone lines. This is great, but the long latency seriously bollixes some common communications protocols. The modem monitors the amount of data in the input buffer to help it decide when to reverse the main channel (there is a small reverse channel squeezed in somewhere), so keeping the modem's (ample) input buffer full is desirable. But simple protocols like xmodem and UUCP g will refuse to send very much data before waiting for an ack. (A more sophisticated protocol, such as zmodem, has no problems and gets great throughput.) So Telebit added a neat hack that makes the modem recognise the start of such a protocol (Shere=, etc), and the modem jumps in and sends the ack itself, then sends the data to the other Trailblazer, which sends it on to the uucico (or whatever) at its end and eats the resultant ack. So each uucico thinks it's connected to something which acks with lightening speed and therefore sends at high speed, while the modems bleem data at each other using a better protocol that isn't so impatient for acks. For a small price in reliability (since the sender gets an ack when the modem has the packet, not when the receiving system has it, leading to an over-optimistic assessment of the amount of data the receiver has if he goes down), you hide all the latency. -- -Colin Plumb
wem@cbnewsc.ATT.COM (william.e.mcgovern) (06/15/89)
From article <188@cat.Fulcrum.BT.CO.UK>, by igb@Fulcrum.BT.CO.UK (Ian G Batten): > > Thanks to this group, my Trailblazer is now working perfectly. But I have > to explain to my management how it works. Does anyone have either a > description (ideal) or pointer to a description of how it works? I've > already found that uucp transfers in UUCP mode (S111=30) are about SIX > times faster than without, so there's obviously some hairy stuff going > on. > > ian My Glasgal Communications Inc. winter '88 catalog has a nice brief description on how the TB+ works. I too will be ordering some TB+'s in the near future and may need help getting them going. If anyone has a canned package of standard hints, please email them to me. I am new to this group, so I've missed any previous discussion. Bill McGovern AT&T Bell Labs att!ttrde!wem 312-982-2855