mTCP updates coming soon: Send me your bug reports

[mbbrutman]

I don't have a recommendation on a good memory tester. There are a few old ones that run in DOS but I don't think they are particularly effective. When things are really bad I break out the DRAM testing device which can test 64K and 256K DRAMs; it works pretty well, but it doesn't work for my later systems with use SIMMs. If the system is new enough memtest86 is a good alternative.

I doubt that your IRQ configuration has an impact on the checksum errors, other than the general observation that RealTek engineers were not taking much pride in their work. ;-0

I uploaded the updated FTP.EXE file to http://www.brutman.com/mTCP/ftp.exe . It just makes it easier to see the number of checksum errors by printing out a line of statistics at the end of a program. I've tested it as best I can, but since I'm not getting any checksum errors it is always 0.

The paper you linked was a good read. Not detecting a checksum error every 1 in 16 million packets can seem like a lot of data, but even my short sessions transferring I was receiving on the order of 100,000 packets and generating an equal amount. For a real machine like an ISP gateway 16 million packets goes by pretty quick. The paper is 20 years old now so the scale of the problem might be different; hardware might be more reliable but we send many more packets now.

[Eudimorphodon]

Most of the RAM in my machine is actually SRAM instead of DRAM. I'd be more enthused about blaming RAM if the machine were acting flakey in other ways, though. As noted, I've been exercising it pretty hard and it's been working great since I swapped out the evil CF card.

(The reason I was running Checkit's RAM test over and over again was I've actually experienced massive hard disk corruption before that traced to bad RAM, which primed me to suspect that before the disk. Apple Power Macs are the %^$&ing worst when it comes to being picky about RAM... but it's hit me on a PC as well.)

I do doubt the IRQ config per se is an issue, the only hail Mary in my mind would be that maybe there's some issue with that hacked generic NE2000 driver that the Realtek-supplied driver won't have. The RTL8019AS is "ne2000 compatible", but phrases like "xxx compatible" often have asterisks behind them.

[maxtherabbit]

Recursive mget is not going to happen any time soon - for reasonably sized directory hierarchies it can work but if somebody goes bananas there is a deeply nested tree of files memory becomes an issue very fast, and dealing with out of memory situations gracefully is a pain. My work-around is to use zip files, and yes, I know this doesn't work unless you have room for the zip file already.

Preserving timestamps should be doable. That's just an optional capability I can add.

maxtherabbit: What does the output from the packet driver loading look like after the soft reset? Nothing mTCP does can survive a reboot, but there might be some crappy state left in the card that is not being flushed out. You might want to try a different version of the packet driver. (Also, send me a trace of when it fails.)

just wanted to say that switching from the crynwr packet driver to the 3com one fixed the warm boot issue!