🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.misc.telefonia
Article #243371

Re: Połączenie modemów przez VoIP

#243371
From: Krzysztof Halasa
Date: Sun, 28 Aug 2022 18:22
179 lines
9186 bytes
"J.F" <jfox_xnospamx@poczta.onet.pl> writes:

>>> W full duplexie nie ma, ale w half duplexie jest.
>>> I do tego sluzy linia RTS ... czy raczj sluzyla ..
>> 
>> Który modem działa (na odcinku DTE-DCE) w half-dupleksie?
>
> Modem-modem mowie. 
> Wtedy sie RTS/CTS przydają.

A jakie dokładnie modemy masz na myśli? Bell 202 i V.23? Wtedy
rzeczywiście, RTS pracuje tak, jak w IBM PC BIOS i RS-232-C
(czy nawet D). Nie wydaje mi się, bym czegoś takiego używał.

Natomiast takie niesymetryczne, ale nie całkiem half-duplex (np. HST)
normalnie działają w full dupleksie z DTE. Jedynie na linii nie ma
symetrii. I owszem, RTS/CTS się przydaje - ale (jak to w modemach)
w sposób full-dupleksowy.

> Nazwa inna, numer obwodu nowy, a numer pinu stary.
> Taka tam zmiana i dodanie.

Nie do końca rozumiem co masz na myśli, ale po prostu dodali.
W szczególności, cały czas jest także "stary" sygnał, na tym samym pinie
RS-232.

> Chyba wszystkie UART mialy ten bufor.
> A 8250 mial az dwa, co wydluza czas do 2*87us.

A źródło tej informacji?
Według producenta (datasheet - właśnie sprawdziłem) 16450 różnił się
tylko timingami (był szybszy). Nie było różnic w schemacie blokowym,
nie było żadnych podwójnych buforów (w sensie przerzutników) itp.

> Najwazniejsze, ze rozkazy INSW/OUTSW byly przerywalne.

Ale nie przez port szeregowy.
Jak dostałeś NMI z kontroli parzystości - to jasne.
Także timer itp.

>> W każdym razie temat pracy dysków vs gubienie znaków na RS-232 to była
>> norma na różnych forach w tamtych czasach (później z modyfikatorami "IO
>> CHRDY" i "bus mastering IDE" w czasach Tritona (a pewnie także wcześniej
>> w czasach Saturna itp)).
>
> Nigdy sie nie spotkalem. 
> Ale moze nie analizowalem.

Przypuszczalnie po prostu nie używałeś modemu V.FC/V.34 z płytą ISA/VLB
(to były główne problematyczne konfiguracje).

Albo ustawiłeś 38400 lub 57600 i jakoś działało - w końcu i tak
przesyłało się głównie dane skompresowane (57 kbps też gubiło dane,
ale sporadycznie).

> Ale bus master to juz pozniejsze czasy ...

Dlatego zapytałem o rok.

>> To w jakiejś równoległej rzeczywistości.
>> Albo w takiej opcji, że program transmitował dane w pollingu
>> z wyłączonymi przerwaniami (na chwilę, np. na czas transmisji bloku).
>> Jak zapewne pamiętasz, były takie rozwiązania (np. IIRC Norton Commander
>> 4 mógł tak robić) - po coś chyba istniały?
>
> Malo prawdopodobne. Przerwanie od uarta dobra rzecz, kto by go nie
> chcial uzywac.

No ale jednak transmisje w pollingu to był fakt, raczej tego nie
wymyśliłem. Był też taki program "lap link" i pewnie inne.

> Natomiast protokól mogl faktycznie czekac az sie dane na dysk zapiszą.

Owszem, i być może pamiętasz jego interakcje z disk cache (write back)?
Bo to też było dość typowym tematem dyskusji :-)
Taki np. Smartdrive w DOSie.

> Nie powiem ci dokladnie - gdzies pod koniec 80tych i w 90-tych.
> od  286 pod dosem, do linuxa na jakims juz przestarzalym 386.

I bez 16550? I przy 115200 bps?
IIRC Rockwella V.32bis nie pracowały przy 115200 bps, to musiał być
jakis szybszy modem. Czy USRy 14k4 itp. działały @ 115200, to już nie
pamiętam. Pamiętasz może jakiego modemu używałeś?

W latach 80 nawet modemy V.32bis jeszcze nie istniały, natomiast problem
115200 bps (w kontekście modemów) pojawił się w latach 90, bliżej połowy
mniej-więcej, razem z V.FC/V.34.

> Tylko o co chodzi - wylaczyles przerwania i czytales kolejne dane?
> o faktycznie jakos tak 1us wychodzila.

Owszem.

> Jacys tam znajomi wczytywali obrazy z kamer, to chwalili jednego z
> moich AT - tam sie dawalo skrocic czasy dostepu, a i DMA bylo szybkie.
> Mowili, ze na innych 386 jest wolniej .. a to jeszcze czasy ISA byly.

Tak mogło być - późniejsze LPC i PCI ("standardowe" porty równoległe)
były wolne. Wcześniejsze maszynki dużo lepiej tolerowały dziwne
ustawienia szyn, rzecz jasna.

> Dla mnie juz sam fakt, ze wieloportowa, sugeruje dziwnosc.
> Przerwania, obsluga, itp.

Przerwanie było jedno. Przy użytym jednym porcie (wtedy też były takie
same problemy). Obsługa była zwykła - przecież to były porty "ISA",
trzeba było tylko wpisać adres i przerwanie.

> ten 386 z jednym portem mialby tylko 11/ms, a sam z 10 razy szybszy.
> Zreszta co tu gdybac - inernetu przez modem nie uzywałes?
> Na 3/486? Z Windows, przeglądarką internetową, pocztą i newsami i ftp?

Jasne że używałem. Tylko jeszcze pamiętam, w jakich konfiguracjach były
problemy, a w jakich nie :-)

>> 2000 przerwań/sekundę byłoby problemem dla tamtego peceta. Ale może
>> pokonywalnym. Natomiast 20 tysięcy przerwań/sekundę by go zabiło.
>
> A mowa tylko o 11 tysiacach.

Bez pollingu na przerwaniach, owszem.
Ale to wciąż zaporowa ilość dla takiego 386 + Windows (albo Linux).

> Jak szybki procesor, to mogly byc takie juz na plycie glownej.
> Ukryte gdzies w chipsetach, wiec niekoniecznie tak wolne jak ISA

No jasne że tak, tylko że to były (odpowiedniki) 16550A, z nimi to ja
wiem że 115200 nie było problemem.

> Juz na 485 dosc powazny, bo jakos sterowac kierunkiem trzeba.
>
> Czekac aktywnie sprawdzając az skonczy?

Typowo adaptery RS-232 - RS-485 same pilnowały timingów, nie wymagały
(ani nie umiały użyć) RTS (ani CTS). Najwyżej była kolizja.

>> które np. rozwiązywano programowo transmitując dodatkowy
>> bajt - miałem raz coś takiego na RS-485).
>
> A moze wlasnie chodzilo o to oproznienie wylaczenia nadajnika?
> dodatkowy bajt, i przychodzi przerwanie kiedy trzeba ...

Tylko tam była własna logika i żadnych 16450 (raczej PIC18).
Oglądałem oscyloskopem, więc widziałem szczegóły. Nadajnik był wyłączany
po ostatnim bicie (STOP), dodatkowego bajtu. Bez tego ostatniego były
(najwyraźniej) problemy.

> A co z uzytkownikami modemow 56k?

W czasach X2, flex56 i V.9x karty/płyty główne z 16550A to była norma.

> Zazwyczaj karta multi-IO, z jakims combo scalakiem, 
> a 16450 ... czy to juz nie czasy "na plycie" ?

Nie. W tamtych czasach praktycznie każdy pecet (pomijając jakieś
Olivetti itp.) miał kartę 2 * RS-232 + LPT. Wszystkie były podobne,
często był tylko jeden scalak do RS-232. Wpisz w google np. GW451C,
będziesz wiedział o co chodzi.

Na płycie były 16550A, z FIFO (jeśli chodzi o typowy, tajwański sprzęt).
To było dopiero w czasach układów SuperI/O. Nie pamiętałem dokładnie,
ale właśnie sprawdziłem, i płyty z Saturnami (486 ISA+PCI) już to miały.
To był jakiś 1994 r. Mam wrażenie że popularne płyty z Saturnami
- typowo dla 486DX4 (low cost) - pojawiły się w tym samym czasie co
płyty dla Pentium 75+ (high end), i później niż Mercury (bardzo high
end, P60/66, mieliśmy takiego tylko jednego - IIRC to był ten głośny
IEEEeee bug (FDIV bug)).

Wcześniej były płyty 486 z VLB, tam nie było raczej SuperI/O na płycie,
i potrzebne były karty. Pamiętam że były karty serial + parallel + 2 HDD
+ (2) FDD VLB, ale one raczej nie miały FIFO. Można (i trzeba) było
wstawić 8-bitową kartę z 16550, rzecz jasna.

> No, jak potrzebowales terminale do unixa, to oczywiscie tak.

Terminale podpinałem Ethernetem, seriale były do modemów.
-- 
Krzysztof Hałasa
Technical Details
Message-ID: <m3r1106xf9.fsf@intrepid.localdomain>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erje.net!feeder.erje.net!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-b-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
References: <9137c096-eed0-46b4-a048-f7f2e75295fbn@googlegroups.com> <108uxk52aws2r.1vhn4o5ffl8cn$.dlg@40tude.net> <1h01audmytjqr.3nlrwt3e3eyj$.dlg@40tude.net> <m3h72kknaz.fsf@intrepid.localdomain> <wu7yswwoetkm$.17fo18l60vjt5.dlg@40tude.net> <m3y1vtyyeq.fsf@intrepid.localdomain> <16jfjbcx9bpkt$.agbjl81nivm7.dlg@40tude.net> <m3edxg2nt8.fsf@intrepid.localdomain> <ddtt0r312est.abzmrt8obfif.dlg@40tude.net> <m3czcxp8dc.fsf@intrepid.localdomain> <17cq9v2hiia5c.5hhfxm97f2y$.dlg@40tude.net> <m3h728e17q.fsf@intrepid.localdomain> <1vmix87l2k510$.1evnm1d4822im.dlg@40tude.net> <m3k06yve27.fsf@intrepid.localdomain> <9287039d32iz.16bswik2el0aa.dlg@40tude.net> <m3tu5y0xod.fsf@intrepid.localdomain> <b0ixs6q9v5ba$.r4nb190kozzq$.dlg@40tude.net>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erje.net!feeder.erje.net!news.uzoreto.com!newsreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-b-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
From: Krzysztof Halasa <khc@pm.waw.pl>
Newsgroups: pl.misc.telefonia
Subject: Re: Połączenie modemów przez VoIP
References: <9137c096-eed0-46b4-a048-f7f2e75295fbn@googlegroups.com> <108uxk52aws2r.1vhn4o5ffl8cn$.dlg@40tude.net> <1h01audmytjqr.3nlrwt3e3eyj$.dlg@40tude.net> <m3h72kknaz.fsf@intrepid.localdomain> <wu7yswwoetkm$.17fo18l60vjt5.dlg@40tude.net> <m3y1vtyyeq.fsf@intrepid.localdomain> <16jfjbcx9bpkt$.agbjl81nivm7.dlg@40tude.net> <m3edxg2nt8.fsf@intrepid.localdomain> <ddtt0r312est.abzmrt8obfif.dlg@40tude.net> <m3czcxp8dc.fsf@intrepid.localdomain> <17cq9v2hiia5c.5hhfxm97f2y$.dlg@40tude.net> <m3h728e17q.fsf@intrepid.localdomain> <1vmix87l2k510$.1evnm1d4822im.dlg@40tude.net> <m3k06yve27.fsf@intrepid.localdomain> <9287039d32iz.16bswik2el0aa.dlg@40tude.net> <m3tu5y0xod.fsf@intrepid.localdomain> <b0ixs6q9v5ba$.r4nb190kozzq$.dlg@40tude.net>
Date: Sun, 28 Aug 2022 20:22:02 +0200
Message-ID: <m3r1106xf9.fsf@intrepid.localdomain>
Cancel-Lock: sha1:qB93wLdb/mgTFF11mNcyJXVOqoo=
MIME-Version: 1.0
Lines: 179
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 195.187.100.13
X-Trace: 1661710929 unt-rea-a-02.news.neostrada.pl 452 195.187.100.13:57988
X-Complaints-To: abuse@news.neostrada.pl
X-Received-Bytes: 9006
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit