iverson@cory.Berkeley.EDU (Tim Iverson) (07/08/87)
In article <9600@orchid.UUCP> egisin@orchid.UUCP writes: >I think they do the high speed serial IO with interrupts disabled >and busy-polling. This works fine under msdos where IO is busy-wait >and the networking and application are a single program. This isn't true. The only special thing done to achieve the 115kb rate is that you must load the divisor yourself. Also, PC's won't run this fast, or rather, they get over-run errors since they aren't fast enough to service the interupt (busy waiting is even slower, and not suitable for a backgound 'process' on MSDOS). >This method of IO would not be feasible under Minix with >an interrupt driven serial driver. >(80 microsecond interrupt response? not with minix) Since MINIX will probably deal with the network only on a packet level, MINIX's speed doesn't matter; gaps between packets waste bandwith, but they do not cause other problems. What does matter is that the CPU must buffer all incoming packets itself. Running a background file server at 115kb brings the system to a screaming halt each time someone accesses the network. This is fine from the point of view of the person making the request, but for the hapless soul who has the data, it is unacceptable - even a very fast service routine will steal at least 50% of the available CPU cycles. Other high baud rates are not much better - most PC's won't run at 57.6kb or at 38.4kb (mine won't unless I goose it to 8mhz). PC's are essentialy limited to 19.2kb. AT's will do 115kb, but in order to preserve user response time on MINIX, the inter-packet gap will have to be large and the packets should be small, which again limits bandwith. This makes the possibility of a serial network sound very grim, but that's not true. It is definitely possible, it will just be slow, no matter how you do it. It will also be alot of work. - Tim Iverson iverson@cory.Berkeley.EDU ucbvax!cory!iverson