On Tue, Sep 09, 2003 at 01:37:53AM +0100, P Witte wrote: > > Peter Graf writes: > > > >Yes, this I know, thanks... I'm perfectly aware of the fragmentation and > of > > >out of order receipt of TCP packets... That doesn't change the fact you > could > > >use the fast interrupt to store as many TCP packet as needed (i.e. when > they > > >come in), into a buffer (organized as a linked list of recieved packets), > > >then to transfer the whole lot of packets to the higher level layers of > the > > >TCP/IP stack at once and every 1/50th of second... > > > > Obviously correct but useless. Try to understand that the problem in your > > approach is latency and can not be solved by buffering, no matter how > > efficient buffering is implemented. > > > > Simple example: A M$ or Unix machine sends a file to the QDOS machine via > > TCP. It will send one or two packets, then stop and wait for ACK. Further > > packets will only be sent after further ACKs. Your ACKs can only be > > generated in 50 Hz rhythm, so packets will crawl one-by-one in 50 Hz > > rhythm. (Or two-by-two, if you're lucky.) > > But does the incoming data need to be processed in any way before > acknowledgement? Why cant the ISR simply receive and buffer the data and > then send the ACK before exiting, leaving any processing to the higher > levels?
my impression is that to do that for TCP you would have to do all of the protocol implementation into the ISR > In our January discussion you mentioned the case of echo. There is nothing > to stop you from implementing time-critical routines, like echo, in the > 'physical layer'. well there is, as long as QDOS won't allow reschedule after interrupts. Echo is supposed to be a normal application and you would not move it into the ISR layer. As I said it isn't hard to change ISR handling in QDOS and I will certainly do it, right now I have other things that need to be done. Richard