I've try to move to the newest ZDS-II 5.2.1 for Acclaim. There was a trouble because this new ZDS doesn't want to display memory locations higher than 0xB7FFFF in its "Memory" debug window, and I historically used 0xC00000 – 0xC7FFFF memory range for CS2 (the module's onboard 512 k SRAM). So I had to change a lot of .linkcmd files. Now it all works except one annoying thing – when I build the "Release" configuration I get numerous warnings 915 (Expression range error). It doesn't seem to prevent the program from working though.
While reviewing and retesting example projects from HACK-RTOS for eZ80 I've found and corrected several bugs in the documentation and example project themselves. No bugs were found in the RTOS though a lot of work went into it since my last post. Mostly in the TCP/IP stack. It now supports the "fast retransmit" feature. This thing was initially devised as a part of so called "congestion control mechanism" to battle TCP packet congestions at the Internet routers. The HACK-RTOS TCP/IP is not for the Internet (though it supports the default router concept, so theoretically it could be used to establish a connection to some host on the Internet). Instead of congestions I was thinking about radio transmissions where TCP packets could be corrupted by the noise. When you send a stream of data and one of the packets gets lost, the fast retransmit feature ensures that the lost packet is retransmitted quickly, long before its retransmission timeout expires. The task of implementing that rather advanced TCP feature (I'm not aware of other TCP/IP stacks for 8-bit controllers that support it) was challenging. Mainly because of my small 64 k address space. To implement it strictly to the letter of RFC-5681 turned out to be impractical. I've done it a little differently. On the first out-of-order TCP segment received I send back two duplicate acknowledges (DupACK's) not one as the RFC demands. This way I send three DupACK's after receiving two out-of-order segments. This amount of DupACK's should be enough to trigger the fast retransmit at the sender. I wouldn't deviate from the RFC if I can buffer enough out-of-order segments, but I can only buffer three such segments. If I receive more out-of-order segments, I have to throw them away and there is no point in such fast retransmit. So my goal was to artificially expedite the fast retransmit.
When I started to test my fast retransmit implementation I was unpleasantly surprised to find out that Windows XP doesn't do it right. Basically, the host that supports the fast retransmit has to do two things: 1 – it must respond with one DupACK on every out-of-order segment received, and 2 – it must retransmit the lost segment after receiving two or three DupACK's. WinXP has no trouble responding with DupACK's (at least no that I'm aware of), but it doesn't fast retransmit a segment. To be precise, it retransmits, but only part of that segment, which is pointless. I still have to wait for the retransmission timeout to receive the vole lost segment.
My hopes turned to more modern Windows 7. Its TCP/IP stack is different than that of XP. I would even say it is better, but still has problems with retransmitting a packet after three DupACK's. It more often than not retransmits without trouble, but sometimes it doesn't, and I have no idea why. I use Microsoft Network Monitor 3.4 to view TCP segments. It is a convenient tool and works well, so everything is quite clear about who is to blame for the delays in transmission – Windows.
I've also tried FreeBSD. It is a reverse of Windows – usually retransmits packets after getting three DupACK's (not always), but doesn't send DupACK's on out-of-order segments. I was under the impression that FreeBSD TCP/IP stack is the best. After all it was they who invented TCP/IP! The bug report is submitted to the FreeBSD team. The link is –
www.freebsd.org/cgi/query-pr.cgi?pr=174535. No response so far, and having seen other bug reports on their site I have no reason to expect a response any time soon.
Linux doesn't use the fast retransmit by default. Instead it uses something called CUBIC. I've investigated the matter and have found a way to turn on a congestion control algorithm called "reno". Fast retransmit should be a part of it. I've tried to turn in on. Nothing happened. No sign of fast retransmit whatsoever. Maybe I've done something wrong.
In the total, I would not say that my efforts were completely in vain. With modern Windows my fast retransmit improves the connection throughput. It could have been better though.
The latest version of HACK-RTOS is here:
depositfiles.com/files/dkg5j1sg7
