🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.misc.telefonia
Article #243342

Re: Połączenie modemów przez VoIP

#243342
From: J.F
Date: Fri, 26 Aug 2022 19:30
118 lines
6285 bytes
On Tue, 23 Aug 2022 23:35:12 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
> 
>> Modem DCE2 sie przestawia na odbior, tyle tylko, ze juz byl w trybie
>> odbioru.
> 
> Nie ma czegoś takiego (w full dupleksie), że modem się przestawia na
> odbiór albo na nadawanie.

W full duplexie nie ma, ale w half duplexie jest.
I do tego sluzy linia RTS ... czy raczj sluzyla ..

>> Zeby to zadziałalo, musisz mocno przedefiniowac sterowanie modemem, 
>> bo to juz ani RS-232, ani V.24.
> 
> Nic z tych rzeczy. Przyznaję, w RS-232 z 1960 r. tego nie było, ale
> później - bez przesady:
> 
> V.24 circuit 133, RS-232 circuit CJ, DB-25 pin 4.
> 
> Direction: TO DCE
> This circuit is used to control the transfer of data (flow control) on
> Circuit BB (Received Data) when an intermediate function such as error
> control is being used in the DCE.
> 
> The ON condition on Circuit CJ (Ready for Receiving) indicates that the
> DTE is capable of receiving data.

Wow - nazwe zmienili? I numer obwodu?

> The OFF condition indicates that the DTE is not capable of receiving
> data and causes the DCE, or the intermediate function, to retain the
> data. In some DCEs the OFF condition on Circuit CJ (Ready for Receiving)
> also causes a signal to be transmitted to the distant DTE causing an OFF
> condition to be placed on Circuit CB (Clear to Send) extending the flow
> control to distant DTE.

Fajne, ale "in some".

>> 8250 byly IMHO wystarczająco szybkie - tam byl inny problem, OIDP - 
>> nie bylo sygnalu dla procesora, ze wysyłanie sie zakonczyło, 
>> wiec mozna juz zdjac sygnal RTS. 
>> Typowym modemom nie przeszkadzalo, tylko jakims half-duples
>> (radiomodemy?) i do dzis RS-485.
> 
> Nie, 8250 ani 16450 nie były "wystarczająco szybkie". To były scalaki
> podpięte do szyny ISA (a właściwie XT-BUS), czasy dostępu (zwłaszcza
> 8250) typu setek ns, były w stanie "zbuforować" ok. jednego bajta
> danych, co oznaczało - przy np. szybkości 115200 bps - kilkadziesiąt,
> a przynajmniej kilkanaście tysięcy przerwań/sekundę. I to pod warunkiem,
> że opóźnienie obsługi nie przekroczy kilkudziesięciu us (dolicz do tego
> zależności czasowe generowane np. przez twarde dyski). 

Opoznienie o jeden czy nawet 2 bajty, czyli 100-200us tolerowane.
A dyski byly przerywalne.

> To po prostu nie miało prawa działać, 

Tyle, ze działało :-)

> chyba że w systemie, który niczego innego w czasie
> transmisji nie robił.

Czesto na dysk zapisywal :-)

> Praktyka była taka, że 16450 działały "od biedy" @ 38400 bps, natomiast
> 8250 @ 9600 bps (albo i nie) - to ostatnie mogło być spowodowane nie

Moze w jakim linuxie, u mnie zawsze chodzilo na 115200.
Nawet w linuxie.

> tylko samym scalakiem, ale także konstrukcją karty wieloportowej, której
> używałem (jednakże 8250 były wolniejsze i mogły wymagać dodatkowych wait
> statów na ISA itp).

Jak miales jakas dziwną kartę, to oczywiscie tak.

Pamietam takie zagadnienie  16 portow, 9600, ale na 8080.
No i ktos podobnie policzyl, ze to nie ma prawa dzialac na
przerwaniach, wiec przerwanie bylo jedno, co 0.5ms, w przerwaniu
sprawdzane wszytkie porty, zapisywane do buforow ... i dzialalo.

> Natomiast takiego czegoś, o czym napisałeś, to ja nie kojarzę.
> Nie żeby to miało związek z modemami, ale wszystkie te scalaki miały
> flagi (sprawdzam: bit 5 w LSR) "Transmit Holding Register Empty" oraz
> (bit 6) "Transmitter Empty", i bez problemu można było ich użyć do
> sterowania (programowego) RTSem.

Faktycznie, ale jesli mnie skleroza nie myli, to jakis tego typu
problem byl.

A moze ... brak przerwania od TE? 
Wpisujesz ostatni bajt, za chwile przjdzie przerwanie THRE, 
wtedy juz nie bedzie nic do wyslania ... ale uart ciagle wysyla.
I trzeba sprawdzac, kiedy sie zakonczy.

>> Ale chodzi o DCE. Łatwo mozna GB transmitowac, a działało, bo:
>> -predkosc portu modemu wczesnie wzrosła, i z transmisją 
>> modem->komputer nie bylo problemu,
> 
> Ale gdyby była, to pecet zdejmował RTS, i wciąż nie było problemu.
> W szczególności z 16550A+, ze względu na FIFO.
> 
>> -wąskim gardłem zrobiło sie polączenie modem-modem,
> 
> To zawsze było wąskim gardłem raczej, nie?
> Połączenie DCE-DTE raczej nigdy nie było wolniejsze niż DCE-DCE.

BYlo takie samo, zanim sie pojawily smartmodemy.

> To działało, bo po prostu handshaking RTS/CTS działał.

IMHO - dzialalo, bo komputery byly szybkie. 
Jak widac, cos tam w definicji zmienili, ale czy wszystkie modemy 
to respektowały?


J.
Technical Details
Message-ID: <9287039d32iz.16bswik2el0aa.dlg@40tude.net>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!news.man.lodz.pl!newsfeed.pionier.net.pl!3.eu.feeder.erje.net!feeder.erje.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-a-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>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!news.man.lodz.pl!newsfeed.pionier.net.pl!3.eu.feeder.erje.net!feeder.erje.net!newsreader4.netcologne.de!news.netcologne.de!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-a-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
From: "J.F" <jfox_xnospamx@poczta.onet.pl>
Subject: Re: Połączenie modemów przez VoIP
Newsgroups: pl.misc.telefonia
User-Agent: 40tude_Dialog/2.0.15.1
MIME-Version: 1.0
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>
Date: Fri, 26 Aug 2022 21:30:53 +0200
Message-ID: <9287039d32iz.16bswik2el0aa.dlg@40tude.net>
Lines: 118
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 83.4.35.148
X-Trace: 1661542254 unt-rea-a-02.news.neostrada.pl 458 83.4.35.148:52586
X-Complaints-To: abuse@news.neostrada.pl
X-Received-Bytes: 6075
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit