mTCP NetDrive: Faster code available for testing

[mbbrutman]

I've spend the past day testing and measuring the code. If you are curious, it's in a spread-sheet where it's easier to digest: NetDrive test code performance

Don't giggle too much when you see the Pentium 133 with the PCI Ethernet card numbers. : )

 

[Krille]

You sound like our management, we have concerns (no matter whether it matters in reality).

Although it's going to be hard for a user to know exactly how small the write buffer needs to be to avoid loss of interrupts, the user can at least configure that. This would only affect the Write & Verify code path. My main concern was something else; Mike thinks the entire Receiver routine must run with interrupts disabled and that is not something a user can fix with a configuration change. It's also not necessary because the packet driver specification allows for interrupts to be enabled in the receiver so any packet driver worth a damn is going to support that. If it turns out that I'm massively wrong and a large percentage of users are affected by crashes because their packet driver don't follow the specification then Mike can in fact easily fix the problem by releasing a new version of NetDrive.

TL;DR: I'm asking Mike to trust the packet driver specification.

 

[Krille]

I've spend the past day testing and measuring the code. If you are curious, it's in a spread-sheet where it's easier to digest: NetDrive test code performance

Don't giggle too much when you see the Pentium 133 with the PCI Ethernet card numbers. : )

Those numbers are impressive, Mike. Is that with the same code as the current release or did you make additional modifications?

 

[mbbrutman]

Although it's going to be hard for a user to know exactly how small the write buffer needs to be to avoid loss of interrupts, the user can at least configure that. This would only affect the Write & Verify code path. My main concern was something else; Mike thinks the entire Receiver routine must run with interrupts disabled and that is not something a user can fix with a configuration change. It's also not necessary because the packet driver specification allows for interrupts to be enabled in the receiver so any packet driver worth a damn is going to support that. If it turns out that I'm massively wrong and a large percentage of users are affected by crashes because their packet driver don't follow the specification then Mike can in fact easily fix the problem by releasing a new version of NetDrive.

TL;DR: I'm asking Mike to trust the packet driver specification.

I didn't say that the receiver routine has to run with interrupts disabled, nor do I believe that. What I have said is that I'm not willing to re-enable interrupts in my receiver routine if they are not already enabled. There is a big difference.

In short, I'm doing what the packet driver is doing. If interrupts are already enabled when my receiver routine is called, great - there will be no timer tick loss. But if interrupts are disabled then I will not enable them, as I have no idea how well the rest of the packet driver is coded and if it is reentrant, especially for those packet drivers that hook the timer interrupt.

---

Edit: I'm going to go a step further and assert that if something enters your code with interrupts disabled and you turn them on, you have a bug. Something in the call chain or interrupt chain before you disabled the interrupts for a reason; they are not expecting them to be enabled again. Turning them back on unexpectedly can crash the system.

The code that disabled the interrupts might be broken or wrong, but as a device driver writer you have the responsibility not to cause unnecessary problems, regardless of who is complying or not complying with specifications. As was pointed out earlier, you can't just go file a github issue and expect that pre-existing code or BIOS routine to get fixed.

mTCP code only disables interrupts where absolutely needed, and it always restores the interrupt state to what it was. I use a pushf, cli, popf sequence to do this. It is safe and the correct way to do it.

 

[mbbrutman]

Those numbers are impressive, Mike. Is that with the same code as the current release or did you make additional modifications?

It is the same code. I updated my IOTest program to use the CMOS clock for timing (or the jrIDE clock, which is equivalent) to avoid any questions about DOS losing time. (I've not updated the disk images with the new code yet. XT class systems without a CMOS clock can't be tested this way; they really need a stopwatch or something like an AST card with a clock.)

ND_Cache tests absolute disk reads, which eliminates any buffering that DOS or the C runtime might be doing. That is good for testing the code performance directly. IOTest is closer to what somebody should expect because there will be the occasional FAT lookups to get to the next cluster, file seeks, etc. that real workloads do too.