-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!newsfeed.pionier.net.pl!3.eu.feeder.erj
e.net!feeder.erje.net!news.uzoreto.com!newsreader4.netcologne.de!news.netcologn
e.de!peer03.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.ams4!peer.am4.highwi
nds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-01.news.ne
ostrada.pl!unt-spo-b-01.news.neostrada.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>
Date: Sun, 28 Aug 2022 20:22:02 +0200
Message-ID: <m...@i...localdomain>
Cancel-Lock: sha1:qB93wLdb/mgTFF11mNcyJXVOqoo=
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
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: a...@n...neostrada.pl
X-Received-Bytes: 9006
Xref: news-archive.icm.edu.pl pl.misc.telefonia:242898
[ ukryj nagłówki ]"J.F" <j...@p...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
Następne wpisy z tego wątku
- 29.08.22 02:58 J.F
- 31.08.22 15:34 Krzysztof Halasa
- 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
Najnowsze wątki z tej grupy
- 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
- Przeniesienie numeru HaloNet -> INEA
- Czy tradycyjna telefonia stacjonarna już nie istnieje?
- AB=45 - co to?
- Szok! Działający automat telefoniczny!
- Modemy sprzętowe PSTN i ISDN Microcom - czy ma to jakąś wartość
- Ciekawe numery 2023
Najnowsze wątki
- 2024-06-13 Jak sklonowac karte pamieci na wieksza?
- 2024-06-12 szukanie żony
- 2024-06-12 Kamera - co obecnie tanie i dobre?
- 2024-06-12 Re: czyszczenie Cepiku
- 2024-06-11 Re: czyszczenie Cepiku
- 2024-06-11 Re: czyszczenie Cepiku
- 2024-06-12 bezpiecznik DC
- 2024-06-12 zasilanie fleksy z samochodu
- 2024-06-12 Laptop 7" mocniejszy niż eeepc
- 2024-06-13 dostałem sms
- 2024-06-13 Łomża => ERP Implementer <=
- 2024-06-13 Katowice => Administrator IT - Virtualization and Containerization <=
- 2024-06-13 Warszawa => Business Unit Manager (Recruitment Business) <=
- 2024-06-13 Gdańsk => Kierownik Działu Spedycji Międzynarodowej <=
- 2024-06-13 Warszawa => Key Account Manager <=