On Mon, 04 Sep 2000, you wrote:
> > That's true. But does it really matter? A unidirectional network seems a
> > lot simpler to me.
>
> It is simpler to code, but slower and harder to get (you really NEED 2
> cables for two computers).
A ring scales just as well as a line:
#nodes #cables:ring #cables:line
2 2 1
3 3 2
4 4 3
etc.
And if the 2-computer case is very important, you can always make a single
cable connecting 2 nodes. But it won't work for larger networks and it isn't
really JoyNet, just partly compatible. I think Laurens even has the schematic
for the 2-computer cable on his JoyNet page.
> That is the negative point of it, indeed. But I still think performance
> decreases much more by using a unidirectional network, especially when the
> network is large. Since there usually is a two-way communication, in a
> unidirectional network the whole ring always needs to be folowed. In a
> bidirectional network, the shortest path can be taken.
In the best case, the bidirectional network will be a factor two faster.
However, since the bandwidth in the "backwards" direction is only half that
of the forward direction, that lowers the gain somewhat.
> > Another problem is the granularity of the waiting loops. If you want to
> > avoid self-modifying code, the fastest waiting loop is DJNZ, which takes
> > 9 cycles for the last loop and 14 cycles for the other loops. So if you
> > want to wait 10 cycles, you'll have to round to 23.
>
> Timing must indeed be thought of. There is no need to round. Loops that
> are the same every time can easily be coded.
Using JP instead of DJNZ, the number of cycles per loop can be made constant.
But it's not possible to get every number of cycles (try 6). Nor is it
possible to have any fine-grained control without using self-modifying code.
And apart from being complex, self-modifying code doesn't work in read-only
memory.
> > And after solving all the complex issues, there will be compromises on
> > performance, so the main advantage of a timed protocol may diminish.
>
> You may be right. Are you suggesting to rewrite the document to a
> unidirectional format?
Yes, please.
And not just unidirectional, but also a protocol without timing.
> I want to know what other users think of this
> before I do it. (so please react if you care about what it will be)
I'm interested too.
> > A collision means that there are two signals on the same wire at the same
> > time. As far as I know, that will never happen with JoyNet. What can
> > happen, is that two neighbours want to send to each other at the same
> > time, but that's no collision.
>
> Hmm, ok. It's a question of definition. I defined a collision as two
> packets going over the same wire while it can handle only one. The cable
> is an abstract line that can carry a stream of data, in this case 3 wires
> of copper.
I think the term "collision" is reserved for overlapping signals on the
hardware level. For example BNC (coax) networks have collisions, when two
network cards send a packet at the same time. When that happens, both packets
are destroyed.
What you are describing has a lot of similarities, but it happens on a higher
level. It is a case where mutual exclusion of two processes (sending and
receiving) using a single resource (the wires) must be guaranteed. A
difference with collisions is that collisions are undetectable until after
they have happened. The mutex (mutual exclusion) can be detected in advance,
although they're not easy to deal with: deadlock is possible if you do it the
wrong way.
> > Maybe we should make JUMP packets large enough to contain IP packets?
> > That would make IP-over-JUMP a lot easier. Actually, maybe JUMP should
> > only describe the network layer and we can send plain IP packets over
> > that.
>
> That is a good idea. But I don't know enough about IP packets to design
> it.
You wouldn't have to design the IP layer, because it already exists. We only
have to find out what the minimum packet size is and whether using IP in a
JoyNet network will work in practice.
I don't know much about IP either, but Adriano Camargo Rodrigues da Cunha
knows (and implemented it in UZIX) and Laurens Holst is now learning (and
implementing) it. Guys, please enlighten us.
> > I agree with Manuel here. It's not about a "best" version, it is simply
> > useful to know the "evolution tree" of a document.
>
> Hmm, ok. So the parent must be named in every document. By the way I don't
> keep my old versions of it and I don't expect others to. There is no
> archive of them, which makes it a bit useless, since you cannot see the
> tree anyway.
There is the mailinglist archive on msxnet.org...
Sometime soon, I'll post a design for a non-timed protocol that can handle
errors. I'm not 100% sure yet it is correct, which is why I didn't release it
before. However, I am not making much progress on my own, so I'll publish it
hoping for some discussion.
UZIX can be useful to test JUMP, because it has every layer of the network
already implemented. JoyNet + JUMP can replace RS232 and we'll have a running
system.
Bye,
Maarten
****
Problems? contact [EMAIL PROTECTED] See also http://www.faq.msxnet.org/
****
