Kabel d-sub 15 pin
łączący  laptopa analogowo z telewizorem LCD/LED

Widziałem w serwisie aukcyjnym nawet 10 metrów, co by mnie juz wystarczało.

Jak długi może być maksymalnie taki przewód?
Są sprzedawane z jakimiś filtrami na końcach, nawet jeden taki filtr mam (składany).

Czy długość (tu 10 metrów) sprzyja powstawaniu zakłóceń lub powoduje zanikanie/słabnięcie sygnału?
Na co zwracać uwagę kupując - po czym odróżnić kabel dobry/znośny/bylejaki?

W dniu 19.07.2010 17:44, Czeslaw P. pisze:

Jak długi może być maksymalnie taki przewód?

Prawie dowolnie, pod warunkiem zastosowania zewnętrznego
wzmacniacza. Robiłem 25 m linię do projektora w auli.

Są sprzedawane z jakimiś filtrami na końcach, nawet jeden taki filtr mam
(składany).

Nie filtrami, ale ferrytami odkłócającymi.

Czy długość (tu 10 metrów) sprzyja powstawaniu zakłóceń lub powoduje
zanikanie/słabnięcie sygnału?

Jedno i drugie.

Na co zwracać uwagę kupując - po czym odróżnić kabel dobry/znośny/bylejaki?

Po grubości i sztywności choćby. Ale nie licz na dobrą jakość
obrazu na jakimkolwiek kablu dłuższym niż 2 m bez zastosowa-
nia wzmacniacza. Już 5 m wymaga dobrego kabla, a 15 m --
wzmocnienia sygnału.

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

Po grubości i sztywności choćby. Ale nie licz na dobrą jakość
obrazu na jakimkolwiek kablu dłuższym niż 2 m bez zastosowa-
nia wzmacniacza. Już 5 m wymaga dobrego kabla, a 15 m --
wzmocnienia sygnału.

Nie do konca prawda. Podlaczalem kabel o dlugosci 15m, bez zadnych wzmacniaczy i obraz byl bardzo dobry. Po prostu kabel byl dobrej jakosci.

R

epsilon$ while read LINE; do echo \>"$LINE"; done < "Robson"

Po grubości i sztywności choćby. Ale nie licz na dobrą jakość
obrazu na jakimkolwiek kablu dłuższym niż 2 m bez zastosowa-
nia wzmacniacza. Już 5 m wymaga dobrego kabla, a 15 m --
wzmocnienia sygnału.

Nie do konca prawda. Podlaczalem kabel o dlugosci 15m, bez zadnych wzmacniaczy i obraz byl bardzo dobry. Po prostu kabel byl dobrej jakosci.

Albo po prostu miałeś szczęście. To trochę tak, jak ze skrętką.
Zrobisz segment dłuższy niż dopuszcza specyfikacja i czasem działa,
a czasem nie. Ale takich rzeczy robić się nie powinno po prostu.
(Inna sprawa, że specyfikacja DVI IIRC nie podaje dopuszczalnej
długości)

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

Albo po prostu miałeś szczęście. To trochę tak, jak ze skrętką.
Zrobisz segment dłuższy niż dopuszcza specyfikacja i czasem działa,
a czasem nie. Ale takich rzeczy robić się nie powinno po prostu.
(Inna sprawa, że specyfikacja DVI IIRC nie podaje dopuszczalnej
długości)

To nie byla kwestia szczescia, to specjalne i dobre wykonanie kabli. Komputer przywieziony wraz z pozostalym sprzetem przez Siemensa, pudlo stoi w sterowni a monitor w bunkrze, zrobili takich dostaw setki, wiec jesli oferuja lable do 25m to po prostu musi dzialac.
Co do skretki to porownanie chybione, dlugosc segmentu wynika z zaleznosci czasowych przy transmisji ramek a nie tlumienia sygnalu.

R

epsilon$ while read LINE; do echo \>"$LINE"; done < "Robson"

Albo po prostu miałeś szczęście. To trochę tak, jak ze skrętką.
Zrobisz segment dłuższy niż dopuszcza specyfikacja i czasem działa,
a czasem nie. Ale takich rzeczy robić się nie powinno po prostu.
(Inna sprawa, że specyfikacja DVI IIRC nie podaje dopuszczalnej
długości)

To nie byla kwestia szczescia, to specjalne i dobre wykonanie kabli. Komputer przywieziony wraz z pozostalym sprzetem przez Siemensa, pudlo stoi w sterowni a monitor w bunkrze, zrobili takich dostaw setki, wiec jesli oferuja lable do 25m to po prostu musi dzialac.

Praktyka, to kwestia wspomagania szczęścia statystyką ;-)

Co do skretki to porownanie chybione, dlugosc segmentu wynika z zaleznosci czasowych przy transmisji ramek a nie tlumienia sygnalu.

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.

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

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.

Tak, to prawda. Standardy najlepiej sie naciagalo w czasach 10base2 - segmenty 400m zdarzaly sie dosyc czesto, bo ceny repeaterow byly kosmiczne.

R

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

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.


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

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                   |
\........................................................../

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:// -/                   |                              |

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                   |
\........................................................../

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:// -/                   |                              |

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                   |
\........................................................../

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/ps2033/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.

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

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                   |
\........................................................../

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.

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

W dniu 04.08.2010 11:52, Mariusz Kruk pisze:

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

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

No cóż, możliwe, że faktycznie od jakiegoś czasu jest to
realizowane w inny sposób. Parę lat temu na wykładzie z
sieci wyraźnie słyszałem o generacji sztucznych kolizji
przez koncentratory przełączające.

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

W dniu 20.07.2010 10:58, Robson pisze:

Nie do konca prawda. Podlaczalem kabel o dlugosci 15m, bez zadnych
wzmacniaczy i obraz byl bardzo dobry. Po prostu kabel byl dobrej jakosci.

Miałeś szczęście, dobry kabel i "liberalny" odbiornik. Z dru-
giej strony typowe kable po 15 m ze sklepu dadzą wyraźne od-
bicia, szczególnie przy lepszych parametrach obrazu (czyli
więcej niż typowe 1024x768 60 Hz dla projektorów multimedial-
nych).

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

Miałeś szczęście, dobry kabel i "liberalny" odbiornik.

Pewnie też dobre wyjście karty graficznej, przerabiałem ten temat kilka lat temu i miałem złe doświadczenie z kartami graficznymi które na wyjściu sygnału do gniazda miały podejrzanie dużo pustych pól lutowniczych na elementy na których zaoszczędzono :)

Użytkownik "Czeslaw P." <czechu.p@op.pl> napisał w wiadomości news:i21rt6$m83$1news.onet.pl...

Jak długi może być maksymalnie taki przewód?

To zależy. :-)
Jakie tłumienie ma kabel i jaka jest częstotliwość sygnału.