Using the QIMSI-QL Link

[Peter]

Hi Jan!

It has probably to do with the speed at which the QL can digest data from the fifo.

Maybe. But as long as we do not understand the mechanism, how blocking on receive data does resume at all when more data arrives, I'm sceptical. The behaviour is just too slow to be explained by performance issues, considering the SGC hardware. You will see yourself, after you soldered your serial adaptor.

Normally a device interrupt, or at least a polling/timer interrupt is required to trigger resume. (In general for a multitasking OS - not just for the QL). Fact is, the QL somehow does resume receive, otherwise SERNET wouldn't work at all. We better find out how.

115200 bps means 288 bytes per 20ms, since the fifo is 512 bytes it should be emptied every frame interrupt.

Yes. That is what I mainly had in mind when designing the hardware FIFOs.

Writing to a physical device will stall interrupts for some time so should be avoided, only RAMdisk is safe.

Firstly: In out use case, it works well for the Q68, with just 16 Bytes receive FIFO. That FIFO would certainly overrun during the storage operation with disabled interrupts. I guess it does not matter for SERNET, because data is written to storage after being received, and not during receive. The handshake probaly continues afterwards.

Secondly: I can add 16 KB receive FIFO if that makes you feel better. The coprocessor can easily do that in software for 115 kBaud.

An extra interrupt handler would have to read bytes from the fifo and store them in an even larger buffer (like in SMSQ/E) but the higher layers still have to be able to digest the data fast enough, else you will have the same problem if the large buffer eventually overflows.

First we need to see if buffer overrun is the problem at all. The hardware FIFO is just as fast as a software buffer would be. A software buffer is not really needed as long as hardware FIFO size is sufficient for the intended protocol.

But it is needed that receive resumes relatively fast after blocking, and an interrupt could provide that.

The current version of the driver doesn't check the overrun bit, maybe a PEEK will show it?

No, there will never be an overrun on the QL side for the SER port use, as my MiniQ68 program never feeds more data into the FIFO than room available. But I should add an overrun indication, maybe a blinking LED or so.

All the best
Peter

[Peter]

Here is another MiniQ68 program for SER-QL transfer at 115200 Baud, sources included. It causes the green QIMSI LED to blink forever, after a receive overrun occured. (The LED toggling mechanism after every byte was removed.) I have tested the overrun detection to work. I see no overrun using SERNET here.

[Derek_Stewart]

Hi,

Sorry to divert attention away, but the talk about SuperHermes SER3, I remembered that the SuperHermes has 6 Serial ports:

SERIAL MOUSE/RTTY
There are three low speed RS232 INPUT ONLY ports - SER4/5/6 (1200bps
down to 28.1bps).
Typical uses:
• RTTY (Radio teletype)
•
Serial mouse. Both Microsoft and Mouse Systems mice are supported in
conjunction with the pointer environment.

Would this have any bearing on the definition of QIMSI SER4?

[Peter]

Sorry to divert attention away, but the talk about SuperHermes SER3, I remembered that the SuperHermes has 6 Serial ports:
[...]
Would this have any bearing on the definition of QIMSI SER4?

You are right inasmuch QIMSI would take away one of three extremely slow ports. I doubt that even one of those will be used in practice, since SER1...SER3 of HERMES can work at more decent speed. If someone actually needs three of those 1200 Baud ports in addition to SER1...SER3, I'm happy to say QIMSI is incompatible to that. The likelihood seems similar to a lottery win of $1000000

But thank you for bringing this up. It is always better to consider possible problems.

[janbredenbeek]

Normally a device interrupt, or at least a polling/timer interrupt is required to trigger resume. (In general for a multitasking OS - not just for the QL). Fact is, the QL somehow does resume receive, otherwise SERNET wouldn't work at all. We better find out how.

Device I/O is controlled by the scheduler loop which executes at least every 20 ms if the machine is in user mode. If there are no other jobs waiting it is executed in rapid succession, since the machine has no other things to do. So doing an IO.FSTRG with no other jobs running will empty the fifo as fast as possible.

One thing that could be optimized are block reads (IO.FSTRG) since IO.SERIO has considerable overhead by calling the fetch byte routine for every byte. But I'm not sure if that will work as I don't know how SERnet reads data without having the source code.

115200 bps means 288 bytes per 20ms, since the fifo is 512 bytes it should be emptied every frame interrupt.

Yes. That is what I mainly had in mind when designing the hardware FIFOs.

Actually it will be a bit less, since there are start- and stopbits (at 10 bits per byte 230 bytes per 20 ms).

First we need to see if buffer overrun is the problem at all. The hardware FIFO is just as fast as a software buffer would be. A software buffer is not really needed as long as hardware FIFO size is sufficient for the intended protocol.
But it is needed that receive resumes relatively fast after blocking, and an interrupt could provide that.

Which is up to the application as there is currently no intermediate buffer. If the application doesn't read that fast, you will have to use an intermediate buffer and an interrupt routine (which is complicated by the fact that reading the status register resets the output bit counter, so writing has to be done with interrupts disabled).

No, there will never be an overrun on the QL side for the SER port use, as my MiniQ68 program never feeds more data into the FIFO than room available. But I should add an overrun indication, maybe a blinking LED or so.

That will certainly be a good debugging aid. But I'm a bit confused about the overrun bit on the QL side, does this work or not?

Jan

[janbredenbeek]

Here is another MiniQ68 program for SER-QL transfer at 115200 Baud, sources included. It causes the green QIMSI LED to blink forever, after a receive overrun occured. (The LED toggling mechanism after every byte was removed.) I have tested the overrun detection to work. I see no overrun using SERNET here.

So this would be a SERnet issue, I think.

How much slower is the SERnet receive compared to two Q68s, or a Q68 and a PC?

[janbredenbeek]

Sorry to divert attention away, but the talk about SuperHermes SER3, I remembered that the SuperHermes has 6 Serial ports:

I guess we need a QIMSI_SER_PORT command

[Peter]

Device I/O is controlled by the scheduler loop which executes at least every 20 ms if the machine is in user mode.

Hmmm... if that leads to just one character received per 20 ms, it might explain the problem. But there should be not much CPU load and the loop should run much more frequently.
Are you sure the OS really checks for pending input in the scheduler loop, even if the driver provides no scheduler task?

That will certainly be a good debugging aid. But I'm a bit confused about the overrun bit on the QL side, does this work or not?

It should work for the FIFO as such. But in our case, the QL-MiniQ68 FIFO is fed by a specific software which never causes an overrun for the QL. The only overrun can happen on the SER receive side of the MiniQ68, and that one will be displayed by a blinking LED.

[Peter]

I guess we need a QIMSI_SER_PORT command

Only after the first user of all 6 Hermes ports, of which 3 are crippled, buys a QIMSI.

[Peter]

How much slower is the SERnet receive compared to two Q68s, or a Q68 and a PC?

The QL sending data feels similar as Q68 and the likes. E.g. getting the QL directory from the Q68 with DIR s2_win1_ feels fine.
Receiving looks like slowing down to a few characters per second, e.g. when the QL tries to receive a Q68 directory with DIR s1_win1_.
The best is to try yourself. Definitely not a performance issue as such. Something is utterly wrong.