USB vs Ethernet?
sinumerik: det där är ju inte sant...
Du kommer få intressanta routingproblem om du använder en publik internetadress på ditt interna nätverk.. Hur ska man veta vilken som efterfrågas? Det är ju precis därför det finns nummerserier resaverade för privata nätverk .... 10.0.0.0 (8) 172.16.0.0 (12) 192.168.0.0 (16)
Och att stora företag bara har ett IP nummer är inte rätt, möjligt att vissa har det, vet dock många små (-50anställda) som har upp till 16 IP... känns väll som lite slöseri men så är fallet...
Du kommer få intressanta routingproblem om du använder en publik internetadress på ditt interna nätverk.. Hur ska man veta vilken som efterfrågas? Det är ju precis därför det finns nummerserier resaverade för privata nätverk .... 10.0.0.0 (8) 172.16.0.0 (12) 192.168.0.0 (16)
Och att stora företag bara har ett IP nummer är inte rätt, möjligt att vissa har det, vet dock många små (-50anställda) som har upp till 16 IP... känns väll som lite slöseri men så är fallet...
-
- Inlägg: 8435
- Blev medlem: 15 april 2006, 18:57:29
- Ort: Typ Nyköping
Det finns ett antal amerikanska företag och universitet som har mer än ett helt A nät själva! Ett A nät är 2^24 adresser!!! Dessutom så är vissa A nät reserverade till hela värlsdelar vilket krånglar till routingtabelerna. Så utdelning gjordes korkat från början vilket gör att det råder IP-adressbrist. Dock så håller jag med om att IPV6 kommer att lösa problemet under ganska lång tid framöver..
- bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
IEEE1394 är inte dött... IEEE1394B kom för inte så länge sedan och erbjuder 800Mbit. IEEE 1394 har blivit stort på macsidan, och DCAM sidan samt till en hel del andra saker. Det finaste med IEEE 1394 är att det har möjlighet att köra DMA vilket är en satans skillnad emot USB om man skall köra med höga datahastigheter och faktist få det att fungera.
Ehternet och TCP/IP behöver inte alls hänga ihop om man inte vill det. Det går mycket väl att köra helt andra saker på det fysiska lagert. Titta exempelvis på GigE-digicams, inte f-n är det något TCP/IP man kör med det nätverkskortet inte.... Men naturligtvis så är det lämpligast i de flesta fallen att köra TCP/IP på ethernet då TCP/IP är bra till det mesta... UDP givetvis inte bortglömt.
Kör IPv6 så slipper ni problem med ont om adresser...
Ehternet och TCP/IP behöver inte alls hänga ihop om man inte vill det. Det går mycket väl att köra helt andra saker på det fysiska lagert. Titta exempelvis på GigE-digicams, inte f-n är det något TCP/IP man kör med det nätverkskortet inte.... Men naturligtvis så är det lämpligast i de flesta fallen att köra TCP/IP på ethernet då TCP/IP är bra till det mesta... UDP givetvis inte bortglömt.
Kör IPv6 så slipper ni problem med ont om adresser...

-
- Inlägg: 3663
- Blev medlem: 11 september 2004, 09:30:42
- Ort: gbg
- Kontakt:
vad onödigt.... är ju 244 oanvändna adresser där..
Ett förslag:
Be din pappa sätta upp trådlösa publika nät lite överallt.
Och begränsa varje nät till 10 användare och låt användarna få publika adresser.
Då kan du ju få ut 23 st acesspunkter på lite olika ställen.
Sedan är det 14 adresser kvar och 10 går till hans avdelning
Dom 4 adresserna som blir kvar kan ju användas till diverse DNS:er och servrar och sånt....
Ett förslag:
Be din pappa sätta upp trådlösa publika nät lite överallt.
Och begränsa varje nät till 10 användare och låt användarna få publika adresser.
Då kan du ju få ut 23 st acesspunkter på lite olika ställen.
Sedan är det 14 adresser kvar och 10 går till hans avdelning
Dom 4 adresserna som blir kvar kan ju användas till diverse DNS:er och servrar och sånt....
-
- Inlägg: 3663
- Blev medlem: 11 september 2004, 09:30:42
- Ort: gbg
- Kontakt:
om man har ett eget C-nät, med egen whois så äger han ju själv adresserna, och då får han säkert dela ut adresserna eller?
När man "köper" ett C-nät så tror jag att egen whoisinformation och abuseinformation följer med....
Eller måste man ha ett B-nät för det?
Dessutom brukar företagsabbonemang inte innehålla några vidareleveransklasuler...
När man "köper" ett C-nät så tror jag att egen whoisinformation och abuseinformation följer med....
Eller måste man ha ett B-nät för det?
Dessutom brukar företagsabbonemang inte innehålla några vidareleveransklasuler...
Kan du ge mig en lista på leverantörer som inte har det?sebastiannielsen skrev: Dessutom brukar företagsabbonemang inte innehålla några vidareleveransklasuler...
Har nämligen gått igenom ett flertal för att hitta någon som tillåter tex fon.com. Men det är tvärstopp... Företagsabb altså, så glocalnet funkar inte..
Och bara en nummerserie ger dig inte access, du måste ju fortfarande ha en ISP för att se till att trafiken når ditt nät.
Håller med i vad du skriver. Har du programmerat några PHY/LLC kretsar (IEEE1394x)? Jag håller själv på att försöka få fart på en hårdvara med PHY/LLC från Texas.bengt-re skrev:Till tgb och mus finns det annars en bra standard som heter PS/2....
USB är bättre än RS-232 eftersom man slipper inställningar, men det är med detta interface och PS/2 som det bör jämnföras. USB är tyvärr väldgt instabilt när det gäller att få tillförlitliga höga transferhastigheter så de förmenta 480Mbit/s är enbart reklam då man aldrig kan designa ett system och lita på att man kommer upp ens i närheten av den hastigheten. Jämnför med IEEE som nominellt är 400Mbit/s och i teorin skulle vara långsammare än USB2. Jag har aldrig upplevt att en IEEE länk varit långsammare än USB2 på grund av att men IEEE så kan man alltid uttnyttja 100% av bandbredden och det utan att stressa ihjäl datorn.
Ett roligt exempel. En DCAM som lastar ungefär 230Mbit/s kan köras på en 700MHz PII med en processorlast på under 5%, en 12Mbit USB kamera stjäl ungefär 15% processorlast på exakt samma platform....
USB ÄR en ersättare för PS/2 och RS-232 och går att använda till mycket, men vill man göra tillförlitliga saker och uttnyttja hög bandbredd så välj hellre IEEE eller ethernet. GigE är ju snabbare än både USB2 och IEEE-B..
Har du erfarenhet av realtidsapplikationer över ethernet? Jag antar att man inte via TCP/IP eller UDP kan allokera någon garanterad bandbredd vilket man kan i IEEE1394 när man kör isokron överföring?
- bengt-re
- EF Sponsor
- Inlägg: 4829
- Blev medlem: 4 april 2005, 16:18:59
- Skype: bengt-re
- Ort: Söder om söder
- Kontakt:
Jag programerar inte dessa själv(vi har så många duktiga programerare på jobbet..), men OHCI-standadern och DCAM standard gör det tämligen lätt att få saker att göra som man vill.
Visst kan man köra realtidsapplikationer över TCP! Givetvis beroende vad man kallar realtid, men i ett låglastat nät som inte är alltför "upphubbat/switchat" så har man låg latency och tillgång till bra bandbredd - vill man ha hela bandbredden till sin applikation så är det likssom bara att slänga in ett till nätverkskort och köra detta till enbart sitt realtidssystem. Lämpligt är att tidsstämpla sina datapaket och synka ihop klockorna med någon lämplig "ping-pong" metod (timstämpla-sänd -> mottagaren gör samma sak tillbaka och utfrån detta kan man synka klockorna och mäta upp sin latency effektivt - kom ihåg att TCP/ip aldrig lovar att paketen kommer fram i rätt ordning - därav lämpligheten att tidsstämpla, MEN i ett enkelt nät så kommer paketen i rätt ordning för det mesta, så visst kan man skippa det om man kommer ihåg att man egentligen har fuskat..)
Ethernet anslutning behöver inte heller innebära att man kör TCP/IP. Man kan använda nätverkskort som en snabb serieport också då det inte finns något som säger att man måste köra TCP/IP på det fysiska lagret (tvärtom fungerar också - det går utmärkt att köra TCP/IP över RS-232 - inte så snabbt dock...
)
Visst kan man köra realtidsapplikationer över TCP! Givetvis beroende vad man kallar realtid, men i ett låglastat nät som inte är alltför "upphubbat/switchat" så har man låg latency och tillgång till bra bandbredd - vill man ha hela bandbredden till sin applikation så är det likssom bara att slänga in ett till nätverkskort och köra detta till enbart sitt realtidssystem. Lämpligt är att tidsstämpla sina datapaket och synka ihop klockorna med någon lämplig "ping-pong" metod (timstämpla-sänd -> mottagaren gör samma sak tillbaka och utfrån detta kan man synka klockorna och mäta upp sin latency effektivt - kom ihåg att TCP/ip aldrig lovar att paketen kommer fram i rätt ordning - därav lämpligheten att tidsstämpla, MEN i ett enkelt nät så kommer paketen i rätt ordning för det mesta, så visst kan man skippa det om man kommer ihåg att man egentligen har fuskat..)
Ethernet anslutning behöver inte heller innebära att man kör TCP/IP. Man kan använda nätverkskort som en snabb serieport också då det inte finns något som säger att man måste köra TCP/IP på det fysiska lagret (tvärtom fungerar också - det går utmärkt att köra TCP/IP över RS-232 - inte så snabbt dock...
