-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.man.lodz.pl!newsfeed.pionier.net.p
l!2.eu.feeder.erje.net!feeder.erje.net!feeder1.feed.usenet.farm!feed.usenet.far
m!newsreader4.netcologne.de!news.netcologne.de!peer01.ams1!peer.ams1.xlned.com!
news.xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.co
m!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!unt-spo-b-01.news.neostrad
a.pl!news.neostrada.pl.POSTED!not-for-mail
From: Krzysztof Halasa <k...@p...waw.pl>
Newsgroups: pl.misc.telefonia
Subject: Re: Połączenie modemów przez VoIP
References: <9...@g...com>
<108uxk52aws2r.1vhn4o5ffl8cn$.dlg@40tude.net>
<1h01audmytjqr.3nlrwt3e3eyj$.dlg@40tude.net>
<m...@i...localdomain>
<wu7yswwoetkm$.17fo18l60vjt5.dlg@40tude.net>
<m...@i...localdomain>
<16jfjbcx9bpkt$.agbjl81nivm7.dlg@40tude.net>
<m...@i...localdomain>
<d...@4...net>
<m...@i...localdomain>
<17cq9v2hiia5c.5hhfxm97f2y$.dlg@40tude.net>
<m...@i...localdomain>
<1vmix87l2k510$.1evnm1d4822im.dlg@40tude.net>
<m...@i...localdomain>
<9...@4...net>
<m...@i...localdomain>
<b0ixs6q9v5ba$.r4nb190kozzq$.dlg@40tude.net>
<m...@i...localdomain>
<1...@4...net>
Date: Wed, 31 Aug 2022 15:34:19 +0200
Message-ID: <m...@i...localdomain>
Cancel-Lock: sha1:1FaYUDI19x2bNhGAsTe7en7KNPE=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Lines: 171
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 195.187.100.13
X-Trace: 1661952867 unt-rea-b-01.news.neostrada.pl 546 195.187.100.13:37410
X-Complaints-To: a...@n...neostrada.pl
X-Received-Bytes: 8560
Xref: news-archive.icm.edu.pl pl.misc.telefonia:242900
[ ukryj nagłówki ]"J.F" <j...@p...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. Chyba że w poborze prądu (w szczególności w porównaniu do wersji
CMOS) :-)
> 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.
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ń.
> 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.
W DOSie nie było żadnych "zadań", które mogły blokować proces
transmisji, to nie był system wielozadaniowy.
> 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.
Czasem pojawiał się kolejny problem, bo potrzebne były 230 i 460 kbps
(w szczególności do "modemów" ISDN, zwłaszcza potrafiących łączyć 2B,
tak jak Courier ISDN albo inne odpowiednie Zyxele). I znów układy na
większości płyt tego nie potrafiły - ale oczywiście to był problem
wielokrotnie mniej powszechny.
> 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.
> 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 :-)
> 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).
> 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.
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, 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.
> A ten system nie znał kolizji, i to bylby problem.
W RS-485 były kolizje, typowo załatwiało się je retransmisjami.
>> 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.
Oglądałem co się działo na linii vs co się działo na RxD/TxD itd.
[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.
> 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.
> 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.
> 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.
--
Krzysztof Hałasa
Następne wpisy z tego wątku
- 31.08.22 17:44 J.F
- 01.09.22 11:45 Krzysztof Halasa
- 01.09.22 16:45 J.F
- 02.09.22 13:39 Krzysztof Halasa
- 02.09.22 17:55 J.F
- 03.09.22 13:25 Krzysztof Halasa
- 04.09.22 20:00 Piotr C.
- 05.09.22 01:01 Krzysztof Halasa
- 08.09.22 21:26 J.F
- 09.09.22 16:00 Krzysztof Halasa
- 09.09.22 22:23 J.F
- 10.09.22 23:24 Krzysztof Halasa
- 15.09.22 17:15 J.F
- 15.09.22 21:56 Krzysztof Halasa
- 16.09.22 06:52 J.F
Najnowsze wątki z tej grupy
- "betamaxy" i inne voip-y dzisiaj
- Hackowanie SS7
- nowe spamerstwo ?
- Przychodzące impulsy telefon nie dzwoni
- Re: Zgody...
- Jak tanio dzwonic do Wielkiej Brytani?
- Chess
- Vitruvian Man - parts 7-11a
- Czas umierać.
- [ot] aplikacja - ameryk. nr. telef + dzwonienie za free do stanow i kanady
- Vectra 'Plan domowy bez limitu'
- Re: Ponownie: Android i zarządzanie książką telefoniczną z komputera
- Re: Ponownie: androSRAJ i zarządzanie książką teleSRAną z bitMłyna
- Re: Ponownie: Android i zarządzanie książką telefoniczną z komputera
- Android, export/import książki telefonicznej
Najnowsze wątki
- 2024-11-29 Dławik CM
- 2024-11-29 [OT] Lewe oprogramowanie
- 2024-11-29 Błonie => Sales Specialist <=
- 2024-11-29 Warszawa => IT Expert (Network Systems area) <=
- 2024-11-29 Warszawa => Ekspert IT (obszar systemów sieciowych) <=
- 2024-11-29 Warszawa => Head of International Freight Forwarding Department <=
- 2024-11-29 Białystok => Inżynier Serwisu Sprzętu Medycznego <=
- 2024-11-29 Pómpy ciepła darmo rozdajoo
- 2024-11-29 Białystok => Application Security Engineer <=
- 2024-11-29 Białystok => Programista Full Stack (.Net Core) <=
- 2024-11-29 Gdańsk => Software .Net Developer <=
- 2024-11-29 Wrocław => Key Account Manager <=
- 2024-11-29 Gdańsk => Specjalista ds. Sprzedaży <=
- 2024-11-29 Chrzanów => Specjalista ds. public relations <=
- 2024-11-27 Re: UseGalileo -- PRODUKTY I APLIKACJE UŻYWAJĄ JUŻ DZIŚ SYSTEMU GALILEO