I only replied to what I didn't agree with or what I had something to say
about. Other things I cut out.
On Wed, 6 Sep 2000, Maarten ter Huurne 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?
> 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.
> Anyway, it could be a gradual system: if you haven't had a transfer in
> a long time, lower the poll frequency.
That is a very good idea, but care must be taken not to make the
calculating of the time before the next poll is done make the system too
inefficient. Also, a minimum frequency should of course be kept, so you
don't have to wait an hour for a reaction after a week not using the
network.
> > 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.
> Do you mean a scheduler? UZIX has one, PC operating systems have one.
Not all PC operating systems do. *-DOS doesn't.
> 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...
Bye,
main(){int c[4] ,x=4 ,l=getpid() ,i;; for( srand(l);c[ x]=- rand
()%6 ,x-- ;);; for( ;44> x;){ char a[9] ,*p=
"%.1f\n", b[9];x=i=0; gets(a);for (l=4 ;l-- ;)x+=-(a[l] -=48)==
(b[l ]=c[ l]); ;for (l=0;16 >i;l =++i %4)x
+=(b[i/4]+ a[l] ?0:( a[l]=b[i/4] =10)) ;printf(p,x *.1) ;};}
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
