🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: pl.misc.telefonia
Article #243374

Re: Połączenie modemów przez VoIP

#243374
From: J.F
Date: Wed, 31 Aug 2022 15:44
219 lines
10248 bytes
On Wed, 31 Aug 2022 15:34:19 +0200, Krzysztof Halasa wrote:
> "J.F" <jfox_xnospamx@poczta.onet.pl> writes:
>>> 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.
>>
>> Nie moze byc "caly czas" na drugi sygnal na tym samym pinie.
> 
> Ależ może i jest, przynajmniej formalnie. RTF V.24 czy inny EIA/TIA-232
> (podobnie np. EIA-530 itd).
> Oczywiście nie może być jednocześnie wykorzystywany, ale jednocześnie
> nie używa się też FD i HD.
> 
>> Bo dzis faktycznie wszedzie pisza o jednym.
> 
> Nigdy nie spotkałem się z informacją, by 8250 był w czymś lepszy niż
> 16450. 

To raczej chodzilo o lepszosc w stosunku do 8251.

> Chyba że w poborze prądu (w szczególności w porównaniu do wersji
> CMOS) :-)

82C50 tez byly.

>> jest jeszcze jedna sprawa - powiedmy ze chwili t=0 konczy sie
>> transmisja bajtu 1,zaraz trafi do bufora, zglosi przerwanie, 
>> bufor sie oprozni. W chwili t~=100us zakonczy sie transmisja 
>> bajtu 2, w 200us bajtu 3, i dwa razy powtorka z rozrywki.
>> Wiec przerwanie trzeba obsluzyc w 100us, ale ... 
>> jesli w t=50us zacznie sie jakis dlugi proces, to moze trwac az do 
>> ~190us, i zablokowac przerwania na ponad 100us.
> 
> Proces nie może blokować przerwań na długi czas, w przeciwnym przypadku
> nawet z buforem znaki będą gubione, i pewnie to nie będą nasze
> największe kłopoty.

Kazdy bajt bufora - 100us dodatkowo.

> Oczywiście normalny proces w ogóle nie może (bezpośrednio) blokować
> przerwań. Takie rzeczy są możliwe tylko w trybie kernela, i raczej są
> wynikiem jakiegoś błędu.
> 
>> O rozkazie mowie. Jak transmisja z HDD odbywala sie przy odblokowanych
>> przerwaniach, to mogl przerwac.
> 
> Transmisja z HDD odbywała się przy odblokowanych przerwaniach, ale port
> szeregowy nie mógł jej przerwać - ponieważ jego przerwania miały mniej
> korzystny priorytet (z wyłączeniem nietypowego IRQ 9).
> 
>> Niestety, nie pamietam juz jak to z 8259 bylo - dalo mu sie powiedziec
>> wczesniej, ze przerwanie zakonczone i moze przyjac kolejne ?
> 
> Oczywiście, ale to nie ten przypadek. Tu mamy sytuację taką, że
> przerwanie nie zostało zakończone (bo np. dysk cały czas wysyłał dane),
> ale mimo tego przerwania są odblokowane. W sensie CPU, ponieważ 8259 nie
> zgłosi w takiej sytuacji "mniej ważnych" przerwań.

A nie mozna 8259 powiedziec, ze juz moze przyjac te mniej wazne?

>> Malo prawdopodobne, 115200 uzywalem do komunikacji pc-pc, i problemow
>> nie pamietam, ale to pod DOS bylo..
> 
> Tam robiono różne sztuczki, by to jakoś działało. Wystarczył smartdrive
> z write backiem by pojawiły się problemy.

Moglem nie uzywac.

> W DOSie nie było żadnych "zadań", które mogły blokować proces
> transmisji, to nie był system wielozadaniowy.

No to przynamniej obsluge przerwania dalo sie szykbko zrobic.

>> A pamietasz SDI/Home Internet Solution? Tam tylko 115200 bylo, i tez
>> nikt nie narzekal. Ale to juz 1999 rok byl, na swiecie moze troche
>> wczesniej.
> 
> Owszem, ale w 1999 r. to już była N-ta iteracja socketów-7
> i późniejszych, wszystkie RSy na płytach od lat miały FIFO.

Te szybkie modemy sie pojawily w okolicac 1995, to moze tez juz bylo
fifo.

>> Na pewno na koncu uzywałem zewnetrznego USR, chyba sportster.
>> Gdzies sie jeszcze kurzy w piwnicy.
> 
> Ważne jaki. 14k4 (+upgrady oficjalne i inne), 28k8 (33k6), X2/V.90+?
> 28k8 i szybsze na pewno działały @ 115200.

Na koncu, wiec juz chyba 56k potrafil.

>> Moglem tez uzywac na karcie ISA - i stad wrazenie, ze dzialalo na
>> 8250.
> Wewnętrzne miały odpowiednik 16550(A). Poza może jakimiś 2400 itp.
> Fakt że większość chyba miała modemy wewnętrzne.

>> Mam wrazenie, ze wszyscy tego uzywali, i nikt nie narzekal.
>> Tzn w windows 3 i w95.
> 
> Ważna kombinacja modemu i peceta.
> Z Windows 3 ludzie typowo nie mieli modemów V.34 i podobnych, w 1995 r.
> "wyszedł" Windows 95, raczej mało prawdopodobne, by ktoś używał
> nowiutkiego modemu ze starodawnym komputerem (odwrotnie, bardziej).
> Wtedy komputery zmieniało się znacznie częściej, po roku to już były
> stare truchła :-)

Jakos tak, ale jak ktos wydał na modem, to moglo go byc nie stac na
komputer przez pewien czas. 
Albo wolal poczekac ze zmianą windows.

>> No i jakis specjalny software, zeby obsugiwal na jednym przerwaniu.
> Nie, to nie wymagało specjalnego softu. Problem z dzieleniem przerwań
> był tylko sprzętowy (nie były wyzwalane poziomem i z otwartym drenem).

ALe przecietny program na jednym przerwaniu obslugiwal jeden port.
Jak trzeba bylo obsluzyc dwa rozne, to klopot.

Moze nie w Unixie, ale juz chyba nawet windows by zwariowal.

>> Wszyscy uzywali, i nikt nie narzekal.
>> Albo windows szybsze, albo w miedzyczasie 8250 i 16450 znikly.
> 
> Problemy z Windows były nawet większe :-) Ale owszem, 16450 znikły.
> 
>> Tylko ze tak patrze - ATX to rok 1995, wczesniej chyba port szeregowy
>> na plycie to rzadkosc.
> 
> Blisko ale nie do końca, spójrz np. na PVI-486SP3 albo PCI/I-486SP3G
> (1994 r.) - AT, ale z SuperI/O i 16550.

No ale to chyba raczej rzadkosc, a nie popularna plyta.

Chociaz ... juz mi skleroza zawodzi - jak IDE przeniesli na plyte,
to chyba przy okazji i porty szeregowe przeniesli.
Jeszcze na tasiemkach i sledziach, ale UART juz na plycie.
PCI jest od 1992, a wraz z nia poznikaly karty multi-IO z IDE ?

> Natomiast SuperI/O na kartach VLB jakoś nie miały seriali z FIFO.
> 
>> Elektronicznie robi sie to nawet bardzo prosto ... ale trzeba znac
>> predkosc. A nie wiadomo, ile komputer ustawi.
> 
> Zwykle wiadomo, 

Ty wiesz, a interfejs/konwerter nie wie. Trzeba jakos powiadomic.

> może z jakąś dokładnością (typu 9600 - 19200) - ale to
> bez takiego znaczenia, najwyżej nieco dłużej będzie na linii.

Bedzie za dlugo, to peryferium zdązy odpowiedziec i trafi w kolizje.

>> A ten system nie znał kolizji, i to bylby problem.
> W RS-485 były kolizje, typowo załatwiało się je retransmisjami.

Przewidzianych nie bylo. 
Wiec za drugim razem tez moze byc za dlugo.

>>> Tylko tam była własna logika i żadnych 16450 (raczej PIC18).
>> Ale pewnie gdzies byl pecet przyłączony do szyny RS-485.
> Tak, przez adapter z Ethernetem. Ale one chyba nie generowały takich
> akcji.
> 
>> Byc moze ten sam problem - brak przerwania przy oproznieniu nadajnika, 
>> i trzeba sobie radzic.
> 
> No ale napisałem, że oglądałem oscyloskopem. BTW nie oglądałem, rzecz
> jasna, co tam się działo w środku, ale tam nie było żadnego 16450 itp.
> więc to raczej bez związku.

No, jak specjalizowany interfejs z ethernetem, to mogli wstawic
dowolną kosc.

> [GW451]
>> Ale to pierwsze czasy opisujesz.
> 
> Tak średnio raczej.
> Przecież nie pisałem o płytach 286, albo inny PC 8088 z 256 KB RAM.

>> w latach 90-tych, to  juz standardem byla karta multi-IO z interfejsem 
>> HDD-IDE i FDD, i jedną koscią, ktora to wszystko obslugiwała.
> 
> Tak, ale to nie było na początku lat 90-tych.

IDE-ATA sie pojawilo w w 1987 (wiki). Popularnosc zdobylo troche
pozniej, 
w Polsce jeszcze ciut pozniej, ale wkrotce nie dało sie innego dysku
kupic, no chyba ze SCSI.

>> A co w tej kosci ... 8250 czy 16550 ... nigdy mnie nie interesowalo
>> :-)
> 
> Płyta główna: 16550. Karta XT-BUS/ISA/VLB: 16450 a wcześniej nawet 8250.
> Pewnie były wyjątki, ale generalnie tak to wyglądało.
> Tzn. wyjątki ew. dotyczyły kart, bo nie pamiętam żadnej płyty z 16450.

Na plycie to ja nie pamietam nawet 16550.
Byly jakies stonogi i mialy wszystko w sobie.

>> to juz chyba byla era "chipsetow" to plyt glownych, to moze
>> Tajwanczycy nie mieli co wymyslac.
> 
> Nie do końca rozumiem, ale "chipsety" były też w 386 i wcześniej w 286.
> Nazwa pochodzi od konkretnego chipsetu (zestawu scalaków) C&T.

A to tajwanska firma ?

>> 1994 czyli jeszcze nie ATX?
>> porty z plyty na śledziach ?
> 
> Owszem. Na płycie były tylko headery.
> 
>> A terminale na poczatku mialy RS-232.
>> I jak bylo trzeba chocby 8, to specjalna karta potrzebna.
> 
> Owszem. Ale to nie ten przypadek.

OK, ale unix mial takie problemy, a windows nie :-)

J.
Technical Details
Message-ID: <8ya4v0v1gm8f.1cmttawuyze7d.dlg@40tude.net>
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.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> <m3r1106xf9.fsf@intrepid.localdomain> <1vc1aqo0h73ph.1k2tgl2wzagtb.dlg@40tude.net> <m3czcgtu3o.fsf@intrepid.localdomain>

Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.farm!news.uzoreto.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: "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> <9287039d32iz.16bswik2el0aa.dlg@40tude.net> <m3tu5y0xod.fsf@intrepid.localdomain> <b0ixs6q9v5ba$.r4nb190kozzq$.dlg@40tude.net> <m3r1106xf9.fsf@intrepid.localdomain> <1vc1aqo0h73ph.1k2tgl2wzagtb.dlg@40tude.net> <m3czcgtu3o.fsf@intrepid.localdomain>
Date: Wed, 31 Aug 2022 17:44:54 +0200
Message-ID: <8ya4v0v1gm8f.1cmttawuyze7d.dlg@40tude.net>
Lines: 219
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 83.4.181.60
X-Trace: 1661960695 unt-rea-b-01.news.neostrada.pl 550 83.4.181.60:57834
X-Complaints-To: abuse@news.neostrada.pl
X-Received-Bytes: 9998
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit