Article View: pl.misc.telefonia
Article #243374Re: Połączenie modemów przez VoIP
From: J.F
Date: Wed, 31 Aug 2022 15:44
Date: Wed, 31 Aug 2022 15:44
219 lines
10248 bytes
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-mailReferences:
<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