Re: [ethmac] Collisions

[nbase <nbase@nbase.com>]

28-Jul-00

   Alex Hi,

           Few comments,

First I didn't draw the sch you see in opencore and just like you I belive
it is still missing many thing and therefore need to be modify.

I would even think that maybe we need to define the back interface as I for
one don't think that DMA is a generic interface I would think that a fifo
interface is more generic but again if the other belive a DMA to be better
than it is fine with me.

the MAC address as well as many other question you and other might have are
still open and this is also why I suggested in an Email in the past that
EACH module in the diagram will have a specification of what it do as well
as its interface (in/out).

Moreover the question of the MAC is not only who generate and where it is
stored but also what the purpose of it as there can be many implemintation
and definition for what this MAC should do starting with only being a
"pure" MAC and in this case there is no need for address recognition etc
only checking the validity of the packet and and similar aspect in the TX
side, or it can be more "smart" one and than it can go to be a bridge,
router etc.

I for one belive that at least for a start a "pure" / simple MAC will do
and the only addition I would think we might want to give is some
information for statistic like number of consecutive colision etc as this
will also help to tell if there is problem in the lines or if there are to
much users in case of shared media. but again this bring us back to the
definition.

I also belive that someone mention it before but maybe we can have sort of
an archive so people can read old emails.

regretly I don't have the spec for fast Eth, however while I might already
forgot few think I did reda it in the past (and it is just as boaring as
the spec for 10M :-) ).

in any case in respect to collision and backoff algoritum the spec specify
(I hope I recall it correct, and if not do corret me) that you will
randomize a number between 0-2^k where K is the number of consecutive
collision and K go up to 10 so after the fisrt collision the random number
can be 0 or 1 after the second consecutive colision the random number can
be 0,1,2,3 and so on. and after the 16 consecutive collision the station
can discard the packet.

but the more common solution I belive is that once you get to the 16 you
reset the "k" and re-try to send the same packet as while it may look as we
will cause a blocking it have no meaning wether we do it with the same
packet or just discard the packet and get the same problem with next packet. 
if the line is "problematic" than it will keep being so and we will have
this blocking and this blocking therefore need to be address in the
"source" sender side.

have a nice day

   Illan





At 11:36 AM 07/28/2000 +0400, you wrote:
>
>
>nbase wrote:
>
>> Hi,
>>
>>    I would be EXTREMLY carefull in changing ANY of the spec definition like
>> the collition you suggested as most spec defineition are not coming "out of
>> the blue" but rather have some importent aspect behind them, which you
>> might not be aware of.
>>
>> a small exmaple is the prevantion of constat head to head collision, not
>> only for any two or more shared port but also what if two of those ports
>> are your own design since the random is the same in both port and since
>> both will start immidiatly than you will never get out of this collision
>> until you reach the 16'th repeteted collision and than both port might want
>> to discard the packet and will continue so until one of them don't have any
>> more packet to transmite. and this is of course a beahve we would not want
>> to happen.
>>
>
>  You'll get the same behavior if you have inquality random number
generator in
>out-of-the-blue design.
>  From what place the seed for random numbers come from, and why there
isn't link
>to random seed on your design? Do you want to get seed from a system
clock? From
>a packets coming through net? I think now your diagrams misses it.
>  At this point, my suggestion is to use both clock and MAC address of the
core
>as a seed for random number generator.
>
>  Concerning MAC address, where did you store it? Where it is compared to the
>recepient's address in the packet? Do you want to leave comparison of
recepient's
>MAC out of your design?
>
>> and the point of saving slot time is also danger as after collision BY
>> DEFINITON each station need to continue transmiting so ALL station will
>> "hear" it for at least extra 32BT (jam), and after this there must be an
>> IPG and so we get back to the traditional
>
>I need to think about it more. Can you mail me some datasheets you have?
>
>> I would also think that any change from the standard should be (if at all)
>> only as an option.
>>    Illan
>
>With best regards, Alex Shayda.
>
>