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.


Reply via email to