Mariusz Kruk pisze:

> Nom. Aczkolwiek porównanie dobre, bo specyfikacja określa "widełki"
> dopuszczalnego opóźnienia propagacji, więc przy kablu przekraczającym
> specyfikację możemy mieć jeszcze dobrą charakterystykę, albo nie.

W przypadku połączeń punkt-punkt (uplink pomiędzy switchami) nie ma
kolizji i ograniczenie długości nie jest tak dotkliwe

--
pozdrawiam
Piotr
XLR250&bmw_f650_dakar

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Piotr Rezmer"
>> Nom. Aczkolwiek porównanie dobre, bo specyfikacja określa "widełki"
>> dopuszczalnego opóźnienia propagacji, więc przy kablu przekraczającym
>> specyfikację możemy mieć jeszcze dobrą charakterystykę, albo nie.
>W przypadku połączeń punkt-punkt (uplink pomiędzy switchami) nie ma
>kolizji i ograniczenie długości nie jest tak dotkliwe

W przypadku sieci na przełącznikach w FD (a taka jest większość sieci
obecnie) w ogóle nie masz kolizji.


--
\------------------------/
| K...@e...eu.org |
| http://epsilon.eu.org/ |
/------------------------\

do góry

W dniu 26.07.2010 08:00, Mariusz Kruk pisze:
> W przypadku sieci na przełącznikach w FD (a taka jest większość sieci
> obecnie) w ogóle nie masz kolizji.

A konkretniej? Bo koncentratory przełączające absolutnie
mogą generować sztuczne kolizje w niektórych przypadkach.
Wyobraź sobie choćby 24-portowy koncentrator, na którym
23 komputery generują ruch do dwudziestego czwartego...

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"
>> W przypadku sieci na przełącznikach w FD (a taka jest większość sieci
>> obecnie) w ogóle nie masz kolizji.
>A konkretniej? Bo koncentratory przełączające absolutnie
>mogą generować sztuczne kolizje w niektórych przypadkach.
>Wyobraź sobie choćby 24-portowy koncentrator, na którym
>23 komputery generują ruch do dwudziestego czwartego...

Nie powinny. Powinny odebrać ramkę i ją najwyżej po cichu spuścić
w /dev/null jeśli się nie mieści w buforze.


--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|

do góry

W dniu 27.07.2010 09:21, Mariusz Kruk pisze:
> Nie powinny. Powinny odebrać ramkę i ją najwyżej po cichu spuścić
> w /dev/null jeśli się nie mieści w buforze.

Ethernet nie powinien gubić ramek, jeżeli nie musi. Lepiej
zgłosić nadawcy sztuczną kolizję i zmusić go do retransmi-
towania ramki po jakimś czasie.

Inna sprawa, że w gigabitowym Ethernecie już się chyba nie
stosuje kolizji, lecz kontrolę przepływu. Ale piszę z pamię-
ci.

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"
>> Nie powinny. Powinny odebrać ramkę i ją najwyżej po cichu spuścić
>> w /dev/null jeśli się nie mieści w buforze.
>Ethernet nie powinien gubić ramek, jeżeli nie musi. Lepiej
>zgłosić nadawcy sztuczną kolizję i zmusić go do retransmi-
>towania ramki po jakimś czasie.

? Po co? To nie ta warstwa.


--
Kruk@ -\ |
}-> epsilon.eu.org |
http:// -/ |
|

do góry

W dniu 27.07.2010 12:02, Mariusz Kruk pisze:
>> Ethernet nie powinien gubić ramek, jeżeli nie musi. Lepiej
>> zgłosić nadawcy sztuczną kolizję i zmusić go do retransmi-
>> towania ramki po jakimś czasie.
>
> ? Po co? To nie ta warstwa.

Ale w standardzie przewidziano wysoką niezawodność sieci. Fi-
zyczna awaria warstwy fizycznej może spowodować utratę pakietu,
ale sama kolizja (a więc zdarzenie mające u podstaw sterowanie
przepływnością, a nie awarię) może opóźniać przesył, ale nie
uniemożliwiać go.

Istnieje zresztą całkiem sporo protokołów zakładających pra-
wie niezawodną pracę Ethernetu. NBF czy IPX są zbudowane w
zasadzie bezpośrednio na bazie warstwy łącza danych Ethenetu.

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"
>>> Ethernet nie powinien gubić ramek, jeżeli nie musi. Lepiej
>>> zgłosić nadawcy sztuczną kolizję i zmusić go do retransmi-
>>> towania ramki po jakimś czasie.
>> ? Po co? To nie ta warstwa.
>Ale w standardzie przewidziano wysoką niezawodność sieci. Fi-
>zyczna awaria warstwy fizycznej może spowodować utratę pakietu,
>ale sama kolizja (a więc zdarzenie mające u podstaw sterowanie
>przepływnością, a nie awarię) może opóźniać przesył, ale nie
>uniemożliwiać go.

Od tego właśnie jest sterowanie przepływem. Wykrywanie kolizji to
zupełnie inna bajka.
Zresztą. Popatrzmy u praktyków:
https://www.cisco.com/en/US/products/hw/modules/ps20
33/products_tech_note09186a008009446d.shtml#topic3
"Note: The information in this document only applies to half-duplex
Ethernet. In full-duplex Ethernet, collision detection is disabled."
Poza tym, full-duplex właśnie z powodu braku konieczności wykrywania
kolizji daje możliwość dłuższych linków eliminując ograniczenia
wynikające z konieczności wykrycia kolizji w określonym czasie.

>Istnieje zresztą całkiem sporo protokołów zakładających pra-
>wie niezawodną pracę Ethernetu. NBF czy IPX są zbudowane w
>zasadzie bezpośrednio na bazie warstwy łącza danych Ethenetu.

Łojezu, weź nie odkopuj tego koszmaru.

--
\.\.\.\.\.\.\.\.\.\.\.\.\.\
.\....@e...eu.org.\.\.
\.http://epsilon.eu.org/\.\
.\.\.\.\.\.\.\.\.\.\.\.\.\.

do góry

W dniu 29.07.2010 08:42, Mariusz Kruk pisze:
> Od tego właśnie jest sterowanie przepływem. Wykrywanie kolizji to
> zupełnie inna bajka.

Ale w Ethernecie do 100 Mbps sterowanie przepływem realizuje
się kolizjami właśnie.

> "Note: The information in this document only applies to half-duplex
> Ethernet. In full-duplex Ethernet, collision detection is disabled."

*detection* is disabled

A dokument dotyczy statystyk pracy interfejsu sieciowego.
Zakładam zatem, że po prostu w FD nie są zliczane kolizje,
bo mają zupełnie inne znaczenie, niż w HD.

--
|"""""""""""""""""""""""""""""""""""""""""""""""""""
"""""""|
| Radosław Sokół | http://www.grush.one.pl/ |
| | Politechnika Śląska |
\...................................................
......./

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Radosław Sokół"
>> Od tego właśnie jest sterowanie przepływem. Wykrywanie kolizji to
>> zupełnie inna bajka.
>Ale w Ethernecie do 100 Mbps sterowanie przepływem realizuje
>się kolizjami właśnie.

Żartujesz?
http://en.wikipedia.org/wiki/Ethernet_flow_control

>> "Note: The information in this document only applies to half-duplex
>> Ethernet. In full-duplex Ethernet, collision detection is disabled."
>*detection* is disabled

Oczywiście. Bo przecież bez wykrycia kolizji interfejs będzie wiedział,
że ta nastąpiła.

>A dokument dotyczy statystyk pracy interfejsu sieciowego.
>Zakładam zatem, że po prostu w FD nie są zliczane kolizje,
>bo mają zupełnie inne znaczenie, niż w HD.

Źle zakładasz. Pisałem Ci już, że kolizji w FD nie ma, co m.in. daje
wydłużenie segmentów.

--
/\-\/\-\/\-\/\-\/\-\/\-\/\
\ K...@e...eu.org /
/ http://epsilon.eu.org/ \
\/-/\/-/\/-/\/-/\/-/\/-/\/

do góry