On Tue, 05 Sep 2000, you wrote:
> I hope you realize that implementing JoyNet in any system which also
> executes other tasks is a highly delicate matter??? It requires a lot of
> fine-tuning, and within a single application that's easy, but with multiple
> apps running...
It's not hard at all if you use a non-timed protocol. I have had this running
for over a year now, except for the fact that it hangs on transmission
errors. Transmission errors are rare in a non-timed protocol, but they can
occur (I got one after sending about 50MB).
The protocol can be fixed: adding CRC and a timeout is sufficient. But I
think a more elegant solution is possible, where you wouldn't need a CRC. A
timeout is always needed, because when the cable is disconnected the protocol
should be able to handle that.
> You see, JoyNet doesn't generate an interrupt to indicate the peer is
> sending/listening, so you'll need to poll continuously,
You have to poll once in a while. For systems like PCs polling 100 times per
second is no problem. And much higher frequencies are possible as well,
although they will start influencing system performance. Anyway, it could be
a gradual system: if you haven't had a transfer in a long time, lower the
poll frequency.
> and your system is
> completely 'locked' while receiving...
If you use a non-timed protocol, you can leave interrupts enabled. To improve
performance of the JoyNet transfer, you can lift the thread priority a bit
above average.
> And the sender can't execute other
> tasks until the receiver has acknowledged the send_request and has received
> all data...
That depends on the protocol.
> It can be done, I think (execute all other processes every int, the
> transmission will hold then but the rest will at least work). However,
> execute-on-int (to give it a name) is quite hard to program I think.
Do you mean a scheduler? UZIX has one, PC operating systems have one.
> However, I don't know how that fits into the architecture of Uzix (I think
> badly).
UZIX is multi-threaded. JoyNet send could be a thread and JoyNet receive
another thread. When there is no transfer, these threads sleep for a while.
When they wake up, they check if a transfer should be started, this is how
you get the polling behaviour. If a transfer was started, the thread will
remain running until the transfer stops.
Note that a running thread is not necessarily active, because there can be
many running threads and CPU time will be shared between them. However, if
the user is waiting for a JoyNet transfer, there will probably be no
foreground process (the user is waiting) and background processes should be
set at a lower priority than the JoyNet transfer, so in result the JoyNet
transfer will get the majority of the CPU time.
Bye,
Maarten
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
