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.)
> QDOS (and likely SMSQ/E, too) is so primitive that an
> interrupt service routine can _not_ trigger immediate rescheduling of jobs
> after it has completed. The time until the next rescheduling can be 20 ms
> (worst case) so the user job has to wait that time until it can process the
> data. The effect is that the other TCP endpoint in the network has to wait
> 20 ms + processing + transfer time until it can react to the response
> packet. Given MTU=1460=1.5KB your interrupt driven approach can not
> guarantee more than a throughput of 1.5 KB / 20 ms = 75 KB/s with TCP, even
> if the other endpoint needs zero time to process it's packets. (75 KB/s is
> not quite what I want.)
Wrong... With my method, you simply get a 20ms penalty (at worst) on the acknowledgment of all the packets that were bufered... I.e. you'll have a (worst case) 20ms penalty when pinging a Q60 on a network, compared to another computer...
Obviously correct, it only supports what I explained. You seem to have the (unrealistic) idea that the other endpoint will be sending (much) more than one packet per ACK.
> Unlike an ISR, a job _can_ trigger immediate rescheduling! You don't need
> to always poll the NIC, a clever approach can lead to full TCP throughput
> during network activity, but zero polling waste (except for a a few tens of
> instructions per 50 Hz) when the network is inactive.
You don't need to poll the hardware as long as you can use an interrupt to signal the arrival of each new packet. Is the Q60 able to trigger an extrenal interrupt on such conditions ? If yes, then the lowest layer of the TCP/IP stack (actually of the Ethernet driver) could be implemented as the external interrupt handler...
Yes the Q60 can trigger those interrupts, yes driver implementation is possible, yes it replaces polling. Irrelevant altogether in a QDOS system, unless I want TCP to crawl.
> 2. You waste response (and processor) time by your second copying level.
> Imagine running the TCP/IP stack on a SuperGoldCard. Copying or not copying
> about 1 MB every second _does_ matter.
Well, aren't we speaking about the Q60 (or Q40) here ? I mean, there's not even an Ethernet I/F on (S)GCs...
Compared to the overhead of the scheduler calls, such a large number of external memory accesses seems relevant to me. Plus your approach doesn't even eliminate the scheduler calls if you want similar TCP response time (and TCP is implemented as a job).
BTW Nasta had the Ethernet design for (S)GC, even the PCB, ready.
> 3. The idea of collecting fragments into larger buffers is not feasible, > unless you implement the TCP/IP stack itself within ISRs. (There are good > reasons not to do that!)
This is wrong... The low level part is only responsible for moving the data from the hardware into an area of the memory wher it can wait until it's processed... I see no problem at all...
You proposed collection of fragments so the job can fetch them in big chunks, i.e. combining the payload. I referred to that.
All the best Peter