-
21. Data: 2016-02-12 15:15:24
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: Piotr Wyderski <p...@n...mil>
J.F. wrote:
> Nie calkiem - Ty robiles to na linii krotkiej, to sie bardziej liczy jak
> filtr RLC.
> Teraz mamy transmisje, przy ktorych kabel robi sie linia dluga :-)
To nie ma znaczenia, Jarku. Jedynym istotnym elementem jest black-box
o zadanym paśmie. A czy to jest drut liczony jako układ o stałych
rozłożonych, czy inny laser, to tylko zaciemnia sprawę.
Pozdrawiam, Piotr
-
22. Data: 2016-02-12 15:23:39
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: Piotr Gałka <p...@c...pl>
Użytkownik "J.F." <j...@p...onet.pl> napisał w wiadomości
news:56bde5ed$0$701$65785112@news.neostrada.pl...
>
>>Nic nie wiem o EFM, ale jeśli opierając się na gwarancji, że każdy stan
>>zawsze trwa co najmniej 3 bity zwiększamy szybkość 3 razy to różnica
>>między
>
> Ale nie zwiekszamy 3 razy, bo z 8 bitow robimy 14 :-)
Pierwszą wypowiedź zrozumiałem tak, że stosując 8/10 nie zmieniamy czasu
bitu i tracimy (z 1,25G robi się 1G).
Natomiast stosując EFM tracimy 2x bo 8 kodujemy na 16 i zyskujemy 3x właśnie
skracając bit 3 razy (był wzór: 1.25G*3*8/16 = 1.875Gbps).
Piszę opierając się wyłącznie na tych informacjach.
> Nie calkiem - Ty robiles to na linii krotkiej,
Mam 1200m skrętki w szufladzie. To chyba już była linia długa.
> jak filtr RLC.
Ta zależność im dłużej stan tym później zbocze bardziej brała się z
półprzewodników niż z linii.
> Poza tym jesli zmienisz dlugo trwajacy stan to impuls przeleci po jakims
> tam czasie, a jesli ten stan bedzie jeszcze dluzej trwal ... to czas
> powinien byc ten sam.
Tak, ale coś przeczuwam, że przy transmisjach o które chodzi nigdy nie ma
długo trwającego stanu, ani tym bardziej jeszcze dłużej trwającego.
> To przy skracaniu zaczynaja wychodzic cuda :-)
A wszystkie stany są krótko trwające.
P.G.
-
23. Data: 2016-02-12 15:35:54
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: "J.F." <j...@p...onet.pl>
Użytkownik "Piotr Wyderski" napisał w wiadomości grup
dyskusyjnych:n9kpds$h33$...@n...news.atman.pl...
J.F. wrote:
>> Nie calkiem - Ty robiles to na linii krotkiej, to sie bardziej
>> liczy jak
>> filtr RLC.
>> Teraz mamy transmisje, przy ktorych kabel robi sie linia dluga :-)
>To nie ma znaczenia, Jarku. Jedynym istotnym elementem jest black-box
>o zadanym paśmie. A czy to jest drut liczony jako układ o stałych
>rozłożonych, czy inny laser, to tylko zaciemnia sprawę.
No nie Piotrze - tzn niby dobrze piszesz, ale diabel tkwi w
szczegolach.
Pierwsza sprawa - a jakie jest pasmo kawalka kabla, np koncentrycznego
? Gigaherce ?
Druga - przy wolnozmiennej petli pradowej dominujacy bedzie wplyw
pojemosci kabla, tzn calkowitej pojemosci.
Calkiem spora moze wyjsc, a prad musi ja przeladowac.
Przy szybkozmiennej trzeba bedzie na to popatrzec jak na linie
transmisyjna - calkiem szybko moze transmitowac, wyjscie moze byc
opoznione od wejscia o pare bitow, ale duzego napiecia na wyjsciu sie
nie uzyska. Bo juz na wejsciu bedzie np 20mA*50 ohm = 1V.
Ktore to 50 ohm przy wolnozmiennnym sygnale w ogole nie ma
uzasadnienia.
A raczej polowa, bo trzeba opornik dopasowujacy, a nawet dwa :-)
Co prawda gdzies tam na wyjsciu linii dlugiej sie ten prad pojawi (tzn
polowa i jeszcze stlumiona), ale detektor trzeba niskonapieciowy.
Taki detektor moze by sobie i z wolnozmiennym poradzil rownie dobrze i
Pawel moglby cos innego napisac :-)
J.
-
24. Data: 2016-02-12 15:38:30
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: Piotr Gałka <p...@c...pl>
Użytkownik "Piotr Wyderski" <p...@n...mil> napisał w wiadomości
news:n9kp7h$55j$1@node1.news.atman.pl...
>
> Przykład ekstremalny: możemy wyzwolić impuls 1ns
> z rozdzielczością również 1ns i robimy to raz na sekundę.
> Czekamy tyle nanosekund od umownego początku, ile wynosi
> wartość elementu do przesłania. Mamy więc zakres 0..999999999
> (~30 bitów) i przesyłamy element z takiego alfabetu raz
> na sekundę -- jedna lub dwie zmiany, zależnie jak chcieć
> to liczyć. Czy to oznacza, że pasmo kabla to 2Hz? :-)
>
Nie rozumiem, jak to się ma do tamtego (w sensie pasma, bo w sensie idei
rozumiem, że to jest to samo tylko bardziej).
Tam było założenie (nie zakładam, że słuszne), że pasmo kabla decyduje o tym
jaki najkrótszy impuls można przesłać i kodując tak, aby bity zawsze były co
najmniej 3 można zwiększyć prędkość 3 razy.
Tutaj zakładając impuls 1ns (dwie zmiany) zakładamy (przez analogię z
poprzednim), że kabel ma pasmo wystarczające do przesłania najkrótszego
impulsu - czyli raczej 1GHz niż 2Hz..
P.G.
-
25. Data: 2016-02-12 15:43:54
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: Piotr Wyderski <p...@n...mil>
J.F. wrote:
> Pierwsza sprawa - a jakie jest pasmo kawalka kabla, np koncentrycznego ?
> Gigaherce ?
W kontekście wątku to nie ma znaczenia. Gigabitowy kabel ma mieć IIRC
pasmo 250MHz na parę przy jakimś tłumieniu i nie jest istotne, czy
Twój ma więcej. Chodzi o to, że wolno mu mieć dokładnie tyle i dalej
spełni normy.
> Druga - przy wolnozmiennej petli pradowej dominujacy bedzie wplyw
> pojemosci kabla, tzn calkowitej pojemosci.
Ale to się w końcu wszystko sprowadzi do tłumienia w funkcji
częstotliwości składowych sygnału i długości kabla (czyli pasma)
oraz zależności ich fazy od tej częstotliwości (czyli dyspersji).
Więcej w tym modelu IMO nie ma, jeśli założymy liniowy zakres
pracy kabla (nie przebija izolacji itp.)
> Calkiem spora moze wyjsc, a prad musi ja przeladowac.
Owszem, to i jeszcze cała masa innych efektów tu będzie miała
udział, ale to efektywnie skończy jako pasmo i dyspersja.
Pozdrawiam, Piotr
-
26. Data: 2016-02-12 15:47:48
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: Piotr Wyderski <p...@n...mil>
Piotr Gałka wrote:
> Tam było założenie (nie zakładam, że słuszne), że pasmo kabla decyduje o
> tym jaki najkrótszy impuls można przesłać i kodując tak, aby bity zawsze
> były co najmniej 3 można zwiększyć prędkość 3 razy.
> Tutaj zakładając impuls 1ns (dwie zmiany) zakładamy (przez analogię z
> poprzednim), że kabel ma pasmo wystarczające do przesłania najkrótszego
> impulsu - czyli raczej 1GHz niż 2Hz..
OK, wersja jeszcze bardziej ekstremalna: po zmianie stanu nie wracamy
już do poprzedniego przez jeszcze jedną sekundę, czyli impuls jest
długi (w zakresie [1..2) sekund).
Pozdrawiam, Piotr
-
27. Data: 2016-02-12 16:57:08
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: Piotr Gałka <p...@c...pl>
Użytkownik "Piotr Wyderski" <p...@n...mil> napisał w wiadomości
news:n9krak$j7r$1@node2.news.atman.pl...
> Piotr Gałka wrote:
>
>> Tam było założenie (nie zakładam, że słuszne), że pasmo kabla decyduje o
>> tym jaki najkrótszy impuls można przesłać i kodując tak, aby bity zawsze
>> były co najmniej 3 można zwiększyć prędkość 3 razy.
>> Tutaj zakładając impuls 1ns (dwie zmiany) zakładamy (przez analogię z
>> poprzednim), że kabel ma pasmo wystarczające do przesłania najkrótszego
>> impulsu - czyli raczej 1GHz niż 2Hz..
>
> OK, wersja jeszcze bardziej ekstremalna: po zmianie stanu nie wracamy
> już do poprzedniego przez jeszcze jedną sekundę, czyli impuls jest
> długi (w zakresie [1..2) sekund).
>
Chyba ogarniam.
Gdybyś napisał, że z tego, że sygnał ma 1Hz (choć wymagana dokładność zbocza
1ns) nie można wyciągać wniosku, że da się go przesłać kablem o paśmie 1Hz
od początku byłoby jasne.
Ale napisałeś jakby odwrotnie - czy z tego, że sygnałowi zdarzyło się mieć
1Hz wynika, że kabel ma 1Hz i to mi nie grało.
P.G.
-
28. Data: 2016-02-12 20:02:37
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: janusz_k <J...@o...pl>
W dniu 2016-02-11 o 19:12, mk pisze:
> W dniu 2016-02-11 18:43, s...@g...com pisze:
>> W dniu czwartek, 11 lutego 2016 14:50:40 UTC+1 użytkownik mk napisał:
>>> Innymi słowy: po przekodowaniu, minimalny
>>> gwarantowany ciąg jednakowych bitów wynosi 3 bity, czyli zmiany stanu
>>> linii nie mogą występować częściej niż co 3 bity.
>>> Zatem używając EFM-plus i nie naruszając limitu linii przesyłowej
>>> 1.25Gprzełączeń/s uzyskujemy transfer:
>>> 1.25G*3*8/16 = 1.875Gbps (!)
>>>
>> Podobnie jak janusz_k ale innymi słowy:
>> Tu sie pomyliles w warunku.
>> Tu będzie tych zmian sygnału gęściej a nie rzadziej. Bo w tych grupach
>> 3 bitowych te bity się będą zmieniać np tak: 101 lub 010 itp. A w
>> sumie będzie bitów na bajt 16.
>
> Nie! Po przekodowaniu EFM-plus nie będzie w strumieniu bitów żadnego
> dowolnego wycinka 3-bitowego jak pokazałeś. Po przekodowaniu jest
> gwarancja, że linia po zmianie stanu, utrzyma swój stan przez co
> najmniej 3 bity! Stąd bity w linii można 3x upakować i czynnik 3 w moim
> wzorze.
Wg mnie nie, zawsze gdzieś się trafi sekwencja szybsza i wtedy pasmo ci
gwałtownie rośnie. A jeżeli nie to się nie da zakodować bo jak Cię
zrozumiałem z 8 bitów robisz 16 tak aby minimalna grupa wynosiła 3 bity
tego samego typu, to oznacza 5 grup + 1 bit czyli de fakto jedna grupa
ma 4 bity, zgadza się? a to oznacza że możesz zakodaować tylko 2^5
stanów a to jest mniej niż 2^8, co oznacza że muszą występować grupy
krótsze 2 lub nawet 1 bitowe, czyli wracamy do tego co napisałem w 1
poście, przepustowość przy tym samym paśmie spada o połowę.
--
Pozdr
Janusz_K
-
29. Data: 2016-02-13 12:03:33
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: Piotr Gałka <p...@c...pl>
Użytkownik "janusz_k" <J...@o...pl> napisał w wiadomości
news:n9la8e$1rb7$1@gioia.aioe.org...
> Wg mnie nie, zawsze gdzieś się trafi sekwencja szybsza i wtedy pasmo ci
> gwałtownie rośnie. A jeżeli nie to się nie da zakodować bo jak Cię
> zrozumiałem z 8 bitów robisz 16 tak aby minimalna grupa wynosiła 3 bity
> tego samego typu, to oznacza 5 grup + 1 bit czyli de fakto jedna grupa ma
> 4 bity, zgadza się? a to oznacza że możesz zakodaować tylko 2^5
2^5 gdy pierwsza grupa jest 4 bity
2^5 gdy druga jest 4 bity
.....
nikt też nie zabronił aby były 4 grupy w tym 5 bitowe.
Nie chce mi się wyszukiwać wszystkich możliwości, ale skoro ktoś to tak
wymyślił to zapewne się da.
P.G.
-
30. Data: 2016-02-13 23:48:59
Temat: Re: Szybkie interfejsy szeregowe -- dlaczego nie np. EFM-plus zamiast 8b10b?
Od: mk <reverse_lp.pw@myzskm>
W dniu 2016-02-12 20:02, janusz_k pisze:
> W dniu 2016-02-11 o 19:12, mk pisze:
>> W dniu 2016-02-11 18:43, s...@g...com pisze:
>>> W dniu czwartek, 11 lutego 2016 14:50:40 UTC+1 użytkownik mk napisał:
>>>> Innymi słowy: po przekodowaniu, minimalny
>>>> gwarantowany ciąg jednakowych bitów wynosi 3 bity, czyli zmiany stanu
>>>> linii nie mogą występować częściej niż co 3 bity.
>>>> Zatem używając EFM-plus i nie naruszając limitu linii przesyłowej
>>>> 1.25Gprzełączeń/s uzyskujemy transfer:
>>>> 1.25G*3*8/16 = 1.875Gbps (!)
>>>>
>>> Podobnie jak janusz_k ale innymi słowy:
>>> Tu sie pomyliles w warunku.
>>> Tu będzie tych zmian sygnału gęściej a nie rzadziej. Bo w tych grupach
>>> 3 bitowych te bity się będą zmieniać np tak: 101 lub 010 itp. A w
>>> sumie będzie bitów na bajt 16.
>>
>> Nie! Po przekodowaniu EFM-plus nie będzie w strumieniu bitów żadnego
>> dowolnego wycinka 3-bitowego jak pokazałeś. Po przekodowaniu jest
>> gwarancja, że linia po zmianie stanu, utrzyma swój stan przez co
>> najmniej 3 bity! Stąd bity w linii można 3x upakować i czynnik 3 w moim
>> wzorze.
> Wg mnie nie, zawsze gdzieś się trafi sekwencja szybsza i wtedy pasmo ci
> gwałtownie rośnie. A jeżeli nie to się nie da zakodować bo jak Cię
> zrozumiałem z 8 bitów robisz 16 tak aby minimalna grupa wynosiła 3 bity
> tego samego typu, to oznacza 5 grup + 1 bit czyli de fakto jedna grupa
> ma 4 bity, zgadza się? a to oznacza że możesz zakodaować tylko 2^5
> stanów a to jest mniej niż 2^8,
Przyznaję, że nie potrafię zrozumieć Twojego wywodu.
> co oznacza że muszą występować grupy
> krótsze 2 lub nawet 1 bitowe, czyli wracamy do tego co napisałem w 1
> poście, przepustowość przy tym samym paśmie spada o połowę.
Powtarzam: przekodowanie EFM-plus daje gwarancję niezmienności stanu
linii częściej niż co 3 bity. I to nie jest jakaś cecha uboczna, ale
właśnie wokół tej cechy EFM-plus został zaprojektowany.
Ok... rozumiem, że masz wątpliwości wynikające z tego, że 16 bitów kodu
wyjściowego, po narzuceniu ograniczenia, że stan linii ma być utrzymany
przez co najmniej przez 3 bity (ale nie dłużej niż 11), nie da 256
możliwości, które potrzebne są do reprezentowania 8-bitów ciągu przed
przekodowaniem. Dodatkowo jeszcze ograniczenie, że po sklejeniu dwóch
dowolnych 16 bitowych kodów wyjściowych również nie będzie naruszona
poprzednia reguła.
No to przeprowadziłem trochę obliczeń...
Z punktu kombinatoryki problem jest podobny do problemu obliczenia "na
ile sposobów można wejść po schodach", gdzie dana jest liczba schodów
przy czym można wykonywać krok zwykły, gdzie posuwamy się o jeden
stopień, albo krok długi, gdzie posuwamy się o dwa stopnie.
Problem rozwiązuje się poprzez odkrycie reguły rekurencyjnej: liczba
możliwych sposobów dotarcia do stopnia n jest równa f(n) = f(n-1)+f(n-2).
Od razu też widać bezpośredni związek z ciągiem Fibonacciego.
Nasz problem jest nieco inny: dozwolone są tylko kroki w których
pokonujemy od 3 stopni do 11 w jednym kroku :-) (ktoś tu ostatnio
narzekał na idealnie okrągłe krowy o nieskończenie małej średnicy).
Z racji tego, że już samo wyprowadzenie wzoru na n-ty element ciągu
Fibonacciego trywialne nie jest, to uznałem, że tym bardziej trywialne
nie będzie dla naszego problemu. Więc sięgnąłem po rozwiązanie
algorytmiczne i sporządziłem na kolanie mały programik to obliczający.
I faktycznie wejść na 16 stopni, przy ww. ograniczeniu, da się na 83
sposoby, czyli to odpowiada log2(83) = 6.375... bitów.
No i gdyby się tu zatrzymać, miałbyś rację -- nie da się.
No ale sprawdźmy na ile sposobów da się wejść na 32 stopni przy ww.
ograniczeniu.
Odpowiedź brzmi: 33961
czyli log2(33961) = 15.0516 bitów. Wciąż nie... ale już prawie.
No to 64 stopnie.
Liczba możliwych sposobów wejść ok. 5.62 mld
czyli log2(5.63 mld) = 32.3891 bitów. DA SIĘ!
Strumień 64 bitów przekodowanych jest w stanie nieść 32 bity danych
oryginalnych!
Gdyby jeszcze interesowało kogoś opcja 512 schodów...
Liczba sposobów 6.57*10^82
Log2(6.57*10^82) = 275.114 bitów.
Czyli widać, że EFM-plus nie jest optymalny bo da nam tutaj możliwość
przeniesienia "jedynie" 256 bitów. Daje on jednak ekstra DC-free i po
prostu, domniemuję, daje się go efektywnie zaimplementować.
Nie znam szczegółów pryncypiów działania EFM-plus, ale nie działa on na
zasadzie prostej "look-up table" 8->16 bitów. Wg wiki po każdym
przekodowaniu 8->16 zapamiętywany jest stan w 4-stanowej maszynie i stan
ten jest uwzględniany w kolejnym przekodowaniu 8->16.
pzdr
mk