Sana2/3, not getting all packets

Or maybe I should call it insana:) Anway, I finally managed to get a stupidly complicated (at least for me) circular buffer system I devised running and it's saving all the packets it gets (checked it with counter inside CopyToBuff() and disk files for network dumps match the counter). The problem is that it's not getting all the packets I want. With requests to packet type 2048 (IP), If I send a CMD_READORPHAN instead of a CMD_READ it doesn't read all the packets for which there are no requests for this task like the Sana docs say, it only gets a few 300 bytes or so. This is when transfering a file almost 4MB! Change it to CMD_READ I get around 300K, so better but still not all packets.
I realized that there is a race condition between 2 device driver users where if one is much faster, the 2nd might not be able to get all the packets the 1st is receiving. So I set the priority of the process sending the requests to 127:) And guess what, similar results!
Is it the device driver that's not sana spec conformant ? This will supposedly be ported to AOS4/MOS later but now I'm testing with a XP64 machine and an A1200 with a Blizzard 1260 running a PCMCIA interface card (NE2000 type of thing) with CNet device driver.
Cheers
José

Could be. I haven't looked at the source code, though. The SANA-II specification does leave room for interpretation, and as these things go, issues are most likely detected and corrected in the most frequently-used parts of the implementation.

Put another way, if CMD_READ or CMD_WRITE didn't work, you wouldn't be using the driver in the first place. But if CMD_READ and CMD_WRITE work fine, but S2_READORPHAN isn't doing exactly what it should be doing, hardly anybody will notice, given that S2_READORPHAN is used so rarely.

It seems you're developing this on a platform which does not support Zorro II PICs. You would be better off with an A2000, A3000, A4000, etc. and something like the Ariadne or Ariadne II cards, both of which (from my experience) implement the SANA-II standard quite well. If you can, borrow a machine with such hardware installed and test it there. The results of the test may be more conclusive than with the driver you are currently trying to put to good use.

The problem with a circular buffer is that is has limited space. Not a problem as long as you can keep up with demand and finish with each entry before it runs to the end. :-)

I assume you have a large number. Do you signal yourself in case of "epoch" and time running out? :-) The smallest I used was 16 entries, for an emulator I worked on, for 16 registers. But that is another story.

Now, having written a device debugger, I know what a mess it can be getting different IO requests from the same or different tasks. As an example, Roadshow dialup will use multithread IO requests. ;-)

In case it gives a clue, I wrote my code to clone the different requests, but I used the orginal one with a pointer. Didn't want the work of needing to allocate or use a circular buffer even; good in theory, in practise can break. IIRC I ended up using the DosPacket method, not what I mostly liked, and stored the IO ReplyPort in the ln_Name pointer. That is used the Name field for my own use.

Then with my own device I changed the replyport and device/unit pointers to the main one to redirect it after I printed out the info. Perhaps this sort of thing may help.

@OBarthel

Theoretically I should get the 4MB of the file size + packet data right ? I do have an A4000 (2 actually) but no network card. I'm thinking of implementing a GUI and then making it available for test.
IIRC the use I'm giving to CMD_READ is probably rare too since it implies the driver keeping the packet for other apps after the 1st user...

@Hypex & All

It was very painful to implement the buffer specially since I just had the idea and went for it, didn't read anything else:) Lots of bugs like the saver thread overrunning the thread that gets packets, sync problems, size problems (packets are of unknown size so they'd overwrite the data sometimes), etc. It currently has 3 threads, one for the main/GUI(not implemented yet), one to get the packets asynchronously and another to save them. They can use the buffer at the same time and mutual exclusion is done via Exec Semaphores and dividing the buffer in chunks. There is also a real time mode that the Saver thread enters, and which other threads have to take into account, where if it's faster than the incoming packets instead of waiting for the next chunk in the buffer to be available it just Saves data as it's received. This probably has a performance penalty, maybe small but still I have two other more options planned already (still not implemented). One that just saves the data in buffer chunk size, other that waits some time for packets to accumulate, if chunk size has not been reached.
I don't know if I'd go the trouble of doing it again right now, or if it even pays off, or if it's even completely bug free, but from the tests I've done so far it seems to be:)
Oh and yes, though also not currently implemented it could easily signal, stop, whatever, when the buffer gets full but right now it doesn't at all, only if I save to floppy, in which case it starts skipping packets (not making requests till space is available).
Another interesting aspect is that one can play with the priorities of the threads and make the buffer very configurable.

If the TCP/IP stack is doing the transfer, the packets involved in that transfer would not be considered orphans according to my interpretation of S2. My driver for 3Com PCMCIA cards should deliver packets to multiple recipients via CMD_READ without problems, but will only deliver a packet via S2_READORPHAN if no user of the driver wanted it.

I'd try CMD_READ with SANA2IOF_RAW and a smart buffer implementation. If you're only using Ethernet, you can quickly check the type field yourself. If frames are dropped because you're too busy parsing the ones that have already arrived, no problem; that's for the transport layer to worry about.