On Fri, 08 Sep 2000, you wrote:
> > 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.
>
> What do you mean with that? Some error-correction algoritm in the protocol
> (equivalent to a CRC)? Or UDP-like transfer, which leaves the
> error-checking to the receiving party?
Error detection other than CRC. Under the assumption that there are only
1-bit errors, the protocol itself can detect errors. I'm not sure this
assumption is correct, but gathering statistical evidence (hours of testing)
should tell us more about that.
> > A timeout is always needed, because when the cable is disconnected the
> > protocol should be able to handle that.
>
> True, but the protocol should not be able to enter a dead lock, as long as
> both computers system memory is not corrupt.
The protocol will deadlock if the cable is disconnected. There is no way to
avoid that. But a timeout will handle those situations and abort the hanging
transfer. A timeout must be viewed as a kind of exception (in Java/C++
terminology), it is not part of the regular protocol.
> > > 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.
>
> In linux, interrupt handlers and their children are not processes and thus
> don't have a priority. If they claim the processor, they'll get it. So
> just ajusting the polling frequency should do. I don't know how uzix does
> this.
Hmmm...
Maybe JUMP in Linux should be implemented in user mode after all? Claiming
the processor for what could be a long time is not a good idea. Or maybe
Linux is fast enough to use one interrupt for every single bit transfer?
Anyway, I still want to be able to play MP3s while a JoyNet transfer is in
progress.
> > Do you mean a scheduler? UZIX has one, PC operating systems have one.
>
> Not all PC operating systems do. *-DOS doesn't.
OK; all multitasking OSes have one.
> > 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.
>
> No, they should not. If one process wants the joynet data, and another
> wants data from memory, there is no reason to priviledge the networking
> process. On normal linux systems, most of the processes (all except the
> ones that don't require any input for a while, like compilers) sleep most
> of the time waiting for data to be ready (from disk, from network, from
> the user via a keyboard, etc.). I think it will be a little different in
> uzix, because most hardware needs to be polled, but I think that still it
> is good to give joynet normal priority. If the system is slow, the network
> is slow...
JUMP also acts as a router, forwarding packets that are intended for another
node. Should other computers in the network suffer if one of them is under
heavy load?
Bye,
Maarten
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
