To send first few UDP packets is without problem. After cca 20 packets MenuetOS crasch. Inserting a very long delay loop between sending UDP packets "solves" this situation, but the time penalty is unaceptable.

Can somebody revise the STACK.INC function 53 fn 7 which is in the 78p2 release unimlemented = corupt?

Viktor

Using 10 msec delay ebx = 1 function 5 int 0x40 solves the problem ...
Now I try to short this delay using my own RDTSC based delay loop.

Viktor

I'll reply to your email on tuesday... It's strange, I haven't seen, and dont expect any problems with UDP.

Mike

Thanks Mike,

if you wish more information or example code, let me know. If you reimplement function 53 fn 7 ... que empty .. ready for writing next UDP packet, all will be OK.

Please can you describe the using of the internal debbugging functions 53 fn 255? Is there something usefull for "TCP/IP endusers".

Many thanks

Viktor

P. S. With 10 ms delay between UDP packets all is working OK.

I'll test this 10ms delay also with telnet that causes crash and reboot to my computer. I hope the root of my problem is the same as that of yours.

Endre.

1/100 time delay function 5 int 0x40 has "another influence to UDP packets", than the RDTSC based time delay alone.

With my own precise >10 ms RDTSC based delay i become UDP lost packets, and chaos in general. In the oposite ebx=1 fn5 int 0x40 works OK.

Why ....

Viktor

Another observations ...

MenuetOS 78pr2 captures 20 UDP packets very quickly to "internal queue", but send each packet to LAN with a litlle more than 10 msec delta time between each UDP packets.

MenuetOS 78pr2 "internal queue length" is 20 packets with total length 96 byte each packet.

Viktor

I tried inserting 10ms delay into the sending process - in vain. Telnet crashes the machine even faster (hopefully I made no mistake .

Endre.

KERNEL.ASM lines 7800dec, 7801dec, and 7811dec, 7812dec are masked.
Original comment "enable these for zero delay between sent packet" is MISTAKE

Enabling these lines, recompiling the Kernel makes an improvement, continuous slow UDP sending of 255 packets is possible - without crasch .....

YOU NEED NOT TO INSERT WAIT STATES between two subsequent UDP packets, but time delay between two UDP packets remains cca 10 msec.

Viktor

P. S. All from MenuetOS 78pr2

Kernel lines commenting is "old story". SourceForge 0.76 final has these lines commented.

The event mechanism is uncler for me, but I hope there can be the 10 msec solution. If the "ready packet" fires no event when ready, 1/100 multitasking mechanism ends this process => 10 msec delay.

Viktor

Hi, first of all the function 53 option 7 command is not implemented because it was some test code that I wrote in the early days for development.

If there is a problem with queueing packets to the ethernet driver, I would rather fix the problem than introduce a 'backdoor' solution :o)

If you really want to monitor the state of the transmit queue you can do it through another function, fn 53 option 255. You can test to see how many entries are in the empty queue using ebx = 100dec. If this is zero then there is no more space to accept a packet for reception or transmission.

Can you give me an example application that I can compile and run to test the problem?

Thanks,

Mike

I just ran a test sending 30 udp packets; I cannot get menuet to crash. So some test code will be very handy.

I ran this test on an pcnet driver so the problem could be with the sis driver, I dont know yet.

The delay of 10ms is another issue which I'll look into and respond later.

Cheers,

Mike

Dear Mike,

now I am preparing the test code as small as possible.

Viktor

Viktor

So Viktor,

If you run this code on your system with a standard kernel.mnt, it will crash, is that correct?

Mike,

YES this is correct.

This code sends sometime 19 dec sometime 20 dec UDP packets NO MORE.
MenuetOS than craschs.

On the modified KERNEL.MNT this code sends cca 250 UDP packets without problems. Time delay >10 msec remains. I have not tested sending more packets at this slow speed.

Viktor

I have been running your code on my PC; a 330MHz Pentium II. fitted with a realtek 8029 card.

It's talking to a 400MHz dell laptop. Two PC connected to a 4 port router.

I'm getting packet transmission times of sub 1ms ( typically 0.2us ), and no crashes. The problem may be your ethernet card. Is it possible for you to at least test a different ethernet card? I'll contact the author and ask him to look at the driver code.

Regards,

Mike.

Thanks Mike a lot for your good news.

I have spare Realtek PCI ENW-9504 card with RTL8139 chip.

Now I wish to test the same code with the new Realtek PCI LAN card. Tomorrow I send results.

Perhaps my friend helps me with his machine too. He has Intel 82** LAN chip on his motherboard.

Many many thanks

Viktor

Dear Mike,

many thanks for your tip (changing the LAN card) and your measurements.

a. disabling the SiS900 card on BIOS level -> no problem
b. instaling the Planet ENW-9504 card with Realtech RTL8139 chip no problem
c. uncommenting the KERNEL.ASM lines 7800, 7801 and 7811, 7812 no problem
d. recompiling KERNEL.MNT no problem
e. transfering 1000 UDP packet using the MIKE.ASM test code no problem
f. DELTA TIME BETWEEN THE UDP PACKETS cca 85 microseconds. Improvments cca 120x

Without uncommenting and recompiling the KERNEL.MNT is such quick UDP transfer impossible.

I have tested another PC running MeOS with Realtek RTL8029 LAN chip. Same good results.

Solution is simple.

a. Please improve the SiS900 driver
b. Please uncomment the above mentioned KERNEL.ASM lines for next distribution

Many thanks again

Good night

Viktor

I've emailed the driver author, hopefully he can have a look. I don't have a sis900 card so cannot do the tests myself.

Do you mind if I ask, what are you using menuet for? It sounds interesting...

Regards,

Mike.