tony@cs.strath.ac.uk (Tony O'Grady) (07/31/90)
Another problem with "Real-Time" responsiveness is the queueing policy used within the node transmit buffers. Work by Thomas E. Marchok, Jay K. Strosnider and Hideyuki Tokuda at CMU has shown that there is commercially available 802.5 hardware which uses FIFO Transmit Queues. Therefore, real-time messages must wait for any previously queued, lower priority messages to be transmitted before the high priority reservation mechanism can come into effect. For FDDI, there are separate Synchronous and Asynchronous transmit queues. However, the Asynchronous queue is FIFO so the expected transmission order from within a station will not occur, i.e., low priority messages will be transmitted BEFORE high priority messages queued later. | Dept. of Computer Science tony@cs.strath.ac.uk | Livingstone Tower, 26 Richmond St. | University of Strathclyde Tel: +44 (0)41 552 4400 ext 3160 | Glasgow, SCOTLAND Fax: +44 (0)41 552 5330 | G1 1XH
vjs@rhyolite.wpd.sgi.com (Vernon Schryver) (08/04/90)
In article <4426@baird.cs.strath.ac.uk>, tony@cs.strath.ac.uk (Tony O'Grady) writes: >... > For FDDI, there are separate Synchronous and Asynchronous transmit queues. > However, the Asynchronous queue is FIFO so the expected transmission order > from within a station will not occur, i.e., low priority messages will be > transmitted BEFORE high priority messages queued later. Would you like to guess what is still not defined in the SMT standard which was recently letter balloted? Yes, there is still no "synchronous bandwidth allocation protocol." I do not see how manually allocated sync bandwidth, is more useful than the mostly automatically allocated async bandwidth. It has been written in stone that no vendor will be criticised for implementing no more than "SMT 5.1" from last year, which lacked many things in following drafts. This means that those who choose not to rush out implementations of whatever protocol is chosen are not supposed to be critisized by those who are waiting for the final standard. (Yeah. I also have this bridge...) If you set the token rotation time very low/fast, limit the number of stations on the ring to much less than the maximum 500, and the stations that you care about do good things with work in their async. queue, will you get reasonable latency? If your frames absolutely, positively have to be delivered in the next 500 microseconds, wouldn't such a small, controlled ring be necessary and sufficient? Were the "guaranteed latency" claims of a few years ago just marketting hipe from those people trying to prove 802.5, MAP, etc. faster than ethernet, driven by a need to sell what they and no one else had? Were the MAP guarantees as silly as those offered for FDDI? (Yes, in Real Life non-speciallized FDDI rings, the worst case latency between opportunties to transmit will be something like 6 orders of magnitude longer than the time required to transmit one frame. As has been said, that's "geologic.") Vernon Schryver vjs@sgi.com