You can hijack the MAC address after the CAM table (not ARP cache) times
out for the switches. However, you can't just listen to their traffic
unless you're on a span port (and span ports don't always work correctly).
VLANing has a number of goals, of which you are listing only one. Another
i
You can hijack the MAC address after the CAM table (not ARP cache) times
out for the switches. However, you can't just listen to their traffic
unless you're on a span port (and span ports don't always work correctly).
VLANing has a number of goals, of which you are listing only one. Another
Vincent Poy wrote:
>
> On Wed, 21 Jul 1999, Modred wrote:
>
> > On Wed, 21 Jul 1999, Vincent Poy wrote:
> >
> > > Speaking about Layer 2 and layer 3. Does the Cisco Catalyst
> > > 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or
> > > just layer 2?
> >
> > Cisco, yes
Vincent Poy wrote:
>
> On Wed, 21 Jul 1999, Modred wrote:
>
> > On Wed, 21 Jul 1999, Vincent Poy wrote:
> >
> > > Speaking about Layer 2 and layer 3. Does the Cisco Catalyst
> > > 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or
> > > just layer 2?
> >
> > Cisco, ye
On Wed, 21 Jul 1999, Modred wrote:
> On Wed, 21 Jul 1999, Vincent Poy wrote:
>
> > Speaking about Layer 2 and layer 3. Does the Cisco Catalyst
> > 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or
> > just layer 2?
>
> Cisco, yes... HP, no clue (perhaps you could ch
On Wed, 21 Jul 1999, Vincent Poy wrote:
> Speaking about Layer 2 and layer 3. Does the Cisco Catalyst
> 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or
> just layer 2?
Cisco, yes... HP, no clue (perhaps you could check their website).
2900XL Architecture Notes:
>
> > That's a option too... Only problem is that can take forever. :-)
>
> Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst
> running 100Mbps.
>
that is due to the spanning tree algorithm being run.
takes about 30 seconds.
you can disable thi
On Wed, 21 Jul 1999, Modred wrote:
> On Wed, 21 Jul 1999, Vincent Poy wrote:
>
> > Speaking about Layer 2 and layer 3. Does the Cisco Catalyst
> > 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or
> > just layer 2?
>
> Cisco, yes... HP, no clue (perhaps you could c
On Wed, 21 Jul 1999, Vincent Poy wrote:
> Speaking about Layer 2 and layer 3. Does the Cisco Catalyst
> 2924XL and the HP ProCurve 2424M and 4000M switches fall under Layer 3 or
> just layer 2?
Cisco, yes... HP, no clue (perhaps you could check their website).
2900XL Architecture Notes:
>
> > That's a option too... Only problem is that can take forever. :-)
>
> Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst
> running 100Mbps.
>
that is due to the spanning tree algorithm being run.
takes about 30 seconds.
you can disable th
On Tue, 20 Jul 1999, Jaye Mathisen wrote:
>
> Perhaps I'm missing something obvious, but since switches forward packets
> selectively per port, I would think it would be hard to sniff packets on
> any port, w/o administrative access to the switch to tell it to mirror
> data to a different port.
On Tue, 20 Jul 1999, Jaye Mathisen wrote:
>
> Perhaps I'm missing something obvious, but since switches forward packets
> selectively per port, I would think it would be hard to sniff packets on
> any port, w/o administrative access to the switch to tell it to mirror
> data to a different port.
On Wed, 21 Jul 1999, Wes Peters wrote:
> Matthew Dillon wrote:
> >
> > :Perhaps I'm missing something obvious, but since switches forward packets
> > :selectively per port, I would think it would be hard to sniff packets on
> > :any port, w/o administrative access to the switch to tell it to mir
On Wed, 21 Jul 1999, Wes Peters wrote:
> Matthew Dillon wrote:
> >
> > :Perhaps I'm missing something obvious, but since switches forward packets
> > :selectively per port, I would think it would be hard to sniff packets on
> > :any port, w/o administrative access to the switch to tell it to mi
:Unmanaged layer 2 switches do that, but the "intelligent" layer 3 switches
:certainly don't. Layer 3 switches can be configured to consider 2 physically
:adjacent ports to be on completely different networks; they will not even
:share broadcast traffic. If you shop carefully, you can even buy sw
:Unmanaged layer 2 switches do that, but the "intelligent" layer 3 switches
:certainly don't. Layer 3 switches can be configured to consider 2 physically
:adjacent ports to be on completely different networks; they will not even
:share broadcast traffic. If you shop carefully, you can even buy s
Vincent Poy wrote:
> Well, the manual doesn't guarantee security either The only
> thing the switch seems to do is give dedicated bandwidth to each port but
> no one knows if it's a true switch since someone did mention a CableTron
> switch being nothing but a bundled of hub ports ins
> > If the switch "just has the default setup" I would recommend that
> > somebody sit down and read the manual and try to *understand* what is
> > happening - probably also try to experiment a bit with the switch
> > configuration. Because what you're seeing is definitely not normal.
>
> We
On Wed, 21 Jul 1999 sth...@nethelp.no wrote:
> > > Then either there is a hub between your net and the switch, or the switch
> > > is badly misconfigured.
> >
> > Well, the switch came out of the box and just had the default
> > setup It just has a IP assigned to it... And there is no hu
On Wed, 21 Jul 1999, Matthew Dillon wrote:
> :Perhaps I'm missing something obvious, but since switches forward packets
> :selectively per port, I would think it would be hard to sniff packets on
> :any port, w/o administrative access to the switch to tell it to mirror
> :data to a different po
> > Then either there is a hub between your net and the switch, or the switch
> > is badly misconfigured.
>
> Well, the switch came out of the box and just had the default
> setup It just has a IP assigned to it... And there is no hub between
> the net and the switch since all the modem
On Wed, 21 Jul 1999 sth...@nethelp.no wrote:
> > No idea, all I know is that people on our LAN without changing MAC
> > addresses can see all traffic going on the LAN. Even from our FreeBSD box
> > with trafshow, we can see traffic that is destined for the global net from
> > the modem dialup
> No idea, all I know is that people on our LAN without changing MAC
> addresses can see all traffic going on the LAN. Even from our FreeBSD box
> with trafshow, we can see traffic that is destined for the global net from
> the modem dialups.
Then either there is a hub between your net and
Vincent Poy wrote:
> Well, the manual doesn't guarantee security either The only
> thing the switch seems to do is give dedicated bandwidth to each port but
> no one knows if it's a true switch since someone did mention a CableTron
> switch being nothing but a bundled of hub ports in
> > If the switch "just has the default setup" I would recommend that
> > somebody sit down and read the manual and try to *understand* what is
> > happening - probably also try to experiment a bit with the switch
> > configuration. Because what you're seeing is definitely not normal.
>
> W
On Wed, 21 Jul 1999, Matthew Dillon wrote:
> :Perhaps I'm missing something obvious, but since switches forward packets
> :selectively per port, I would think it would be hard to sniff packets on
> :any port, w/o administrative access to the switch to tell it to mirror
> :data to a different port
On Wed, 21 Jul 1999 [EMAIL PROTECTED] wrote:
> > > Then either there is a hub between your net and the switch, or the switch
> > > is badly misconfigured.
> >
> > Well, the switch came out of the box and just had the default
> > setup It just has a IP assigned to it... And there is no h
On Wed, 21 Jul 1999, Matthew Dillon wrote:
> :Perhaps I'm missing something obvious, but since switches forward packets
> :selectively per port, I would think it would be hard to sniff packets on
> :any port, w/o administrative access to the switch to tell it to mirror
> :data to a different p
> > Then either there is a hub between your net and the switch, or the switch
> > is badly misconfigured.
>
> Well, the switch came out of the box and just had the default
> setup It just has a IP assigned to it... And there is no hub between
> the net and the switch since all the mode
On Wed, 21 Jul 1999 [EMAIL PROTECTED] wrote:
> > No idea, all I know is that people on our LAN without changing MAC
> > addresses can see all traffic going on the LAN. Even from our FreeBSD box
> > with trafshow, we can see traffic that is destined for the global net from
> > the modem dialu
> No idea, all I know is that people on our LAN without changing MAC
> addresses can see all traffic going on the LAN. Even from our FreeBSD box
> with trafshow, we can see traffic that is destined for the global net from
> the modem dialups.
Then either there is a hub between your net and
:Perhaps I'm missing something obvious, but since switches forward packets
:selectively per port, I would think it would be hard to sniff packets on
:any port, w/o administrative access to the switch to tell it to mirror
:data to a different port.
:
:ie, if I'm plugged into port 1, I can't see tra
Perhaps I'm missing something obvious, but since switches forward packets
selectively per port, I would think it would be hard to sniff packets on
any port, w/o administrative access to the switch to tell it to mirror
data to a different port.
ie, if I'm plugged into port 1, I can't see traffic
On Wed, 21 Jul 1999, Matthew Dillon wrote:
> :Perhaps I'm missing something obvious, but since switches forward packets
> :selectively per port, I would think it would be hard to sniff packets on
> :any port, w/o administrative access to the switch to tell it to mirror
> :data to a different por
:Perhaps I'm missing something obvious, but since switches forward packets
:selectively per port, I would think it would be hard to sniff packets on
:any port, w/o administrative access to the switch to tell it to mirror
:data to a different port.
:
:ie, if I'm plugged into port 1, I can't see tr
Perhaps I'm missing something obvious, but since switches forward packets
selectively per port, I would think it would be hard to sniff packets on
any port, w/o administrative access to the switch to tell it to mirror
data to a different port.
ie, if I'm plugged into port 1, I can't see traffic
On Tue, 20 Jul 1999, Modred wrote:
> On Tue, 20 Jul 1999, Vincent Poy wrote:
>
> > No idea but it seems like the people who sold the Cisco switches
> > atleast claimed that each port is supposed to be secure to prevent packet
> > sniffing by people on the other ports...
>
> Perhaps they were
On Tue, 20 Jul 1999, Modred wrote:
> On Tue, 20 Jul 1999, Vincent Poy wrote:
>
> > No idea but it seems like the people who sold the Cisco switches
> > atleast claimed that each port is supposed to be secure to prevent packet
> > sniffing by people on the other ports...
>
> Perhaps they wer
On Tue, 20 Jul 1999, Vincent Poy wrote:
> No idea but it seems like the people who sold the Cisco switches
> atleast claimed that each port is supposed to be secure to prevent packet
> sniffing by people on the other ports...
Perhaps they were touting 'VLANs'? I can see seperate/many, logi
On Tue, 20 Jul 1999, Vincent Poy wrote:
> No idea but it seems like the people who sold the Cisco switches
> atleast claimed that each port is supposed to be secure to prevent packet
> sniffing by people on the other ports...
Perhaps they were touting 'VLANs'? I can see seperate/many, log
On Tue, 20 Jul 1999 sth...@nethelp.no wrote:
> > > You see the MAC of the switch's port. It's been too long since I've
> > > played on a Catalyst... but what does 'sh arp' display? Any arp -> port
> > > -> host correlations? Good luck... :)
> >
> > Even if it did show the arp of the actu
> > You see the MAC of the switch's port. It's been too long since I've
> > played on a Catalyst... but what does 'sh arp' display? Any arp -> port
> > -> host correlations? Good luck... :)
>
> Even if it did show the arp of the actual host, it's useless if it
> doesn't show the IP of t
On Tue, 20 Jul 1999 [EMAIL PROTECTED] wrote:
> > > You see the MAC of the switch's port. It's been too long since I've
> > > played on a Catalyst... but what does 'sh arp' display? Any arp -> port
> > > -> host correlations? Good luck... :)
> >
> > Even if it did show the arp of the act
On Mon, 19 Jul 1999, Modred wrote:
> > I'm not sure if it shows the mac address of the cisco's port or
> > the actual device connected to it...
>
> You see the MAC of the switch's port. It's been too long since I've
> played on a Catalyst... but what does 'sh arp' display? Any arp -> port
> > You see the MAC of the switch's port. It's been too long since I've
> > played on a Catalyst... but what does 'sh arp' display? Any arp -> port
> > -> host correlations? Good luck... :)
>
> Even if it did show the arp of the actual host, it's useless if it
> doesn't show the IP of
On Mon, 19 Jul 1999, Modred wrote:
> On Sat, 17 Jul 1999, Vincent Poy wrote:
>
>
>
> > > > By reading the man page?
> > > The manpage doesn't really say anything about how to use ttcp...
>
> I don't think manpage useage is -hackers-esque.
I know.
> > There is no ttcp binary any
On Mon, 19 Jul 1999, Modred wrote:
> > I'm not sure if it shows the mac address of the cisco's port or
> > the actual device connected to it...
>
> You see the MAC of the switch's port. It's been too long since I've
> played on a Catalyst... but what does 'sh arp' display? Any arp -> port
On Mon, 19 Jul 1999, Modred wrote:
> On Sat, 17 Jul 1999, Vincent Poy wrote:
>
>
>
> > > > By reading the man page?
> > > The manpage doesn't really say anything about how to use ttcp...
>
> I don't think manpage useage is -hackers-esque.
I know.
> > There is no ttcp binary an
On Sat, 17 Jul 1999, Vincent Poy wrote:
> > > By reading the man page?
> > The manpage doesn't really say anything about how to use ttcp...
I don't think manpage useage is -hackers-esque.
> There is no ttcp binary anywhere on either my -CURRENT,
> 3.2-RELEASE and 3.1-RELEASE systems
On Sun, 18 Jul 1999, Vincent Poy wrote:
> I'm not sure if it shows the mac address of the cisco's port or
> the actual device connected to it...
You see the MAC of the switch's port. It's been too long since I've
played on a Catalyst... but what does 'sh arp' display? Any arp -> port
->
On Sun, 18 Jul 1999, Vincent Poy wrote:
> I'm not sure if it shows the mac address of the cisco's port or
> the actual device connected to it...
You see the MAC of the switch's port. It's been too long since I've
played on a Catalyst... but what does 'sh arp' display? Any arp -> port
->
On Sat, 17 Jul 1999, Vincent Poy wrote:
> > > By reading the man page?
> > The manpage doesn't really say anything about how to use ttcp...
I don't think manpage useage is -hackers-esque.
> There is no ttcp binary anywhere on either my -CURRENT,
> 3.2-RELEASE and 3.1-RELEASE systems.
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote:
> Hi ..
>
> > > 1. If you want to test the network speed ... use ttcp or something
> > >that generates the data and doesn't read it from disk.
> >
> > ttcp works. The only problem is when I tried it in both
> > directions, at once. the t
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote:
> Hi ..
>
> > > 1. If you want to test the network speed ... use ttcp or something
> > >that generates the data and doesn't read it from disk.
> >
> > ttcp works. The only problem is when I tried it in both
> > directions, at once. the
> We have previously done many network performance tests for our
> products running on FreeBSD ...
>
> We have found that when ever there is disk accessing involved, it
> is not a good idea to look at the transfer figures. We did tests
> with ftp and is was slow (compared to only memory genera
> We have previously done many network performance tests for our
> products running on FreeBSD ...
>
> We have found that when ever there is disk accessing involved, it
> is not a good idea to look at the transfer figures. We did tests
> with ftp and is was slow (compared to only memory gener
Hi ..
> > 1. If you want to test the network speed ... use ttcp or something
> >that generates the data and doesn't read it from disk.
>
> ttcp works. The only problem is when I tried it in both
> directions, at once. the total becomes 11.xMbytes/sec total as opposed to
> 9.4Mbytes/se
Hi ..
> > 1. If you want to test the network speed ... use ttcp or something
> >that generates the data and doesn't read it from disk.
>
> ttcp works. The only problem is when I tried it in both
> directions, at once. the total becomes 11.xMbytes/sec total as opposed to
> 9.4Mbytes/s
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote:
> Hi ...
>
> We have previously done many network performance tests for our
> products running on FreeBSD ...
>
> We have found that when ever there is disk accessing involved, it
> is not a good idea to look at the transfer figures. We did tes
Hi ...
We have previously done many network performance tests for our
products running on FreeBSD ...
We have found that when ever there is disk accessing involved, it
is not a good idea to look at the transfer figures. We did tests
with ftp and is was slow (compared to only memory generated d
On Sun, 18 Jul 1999, Jonathan M. Bresler wrote:
> > I guess I forgot about the overhead. I've tested between two
> > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL
> > Switch Full Duplex and never seen anything close to the speeds.
>
> using netperfv2pl3 and
On Sun, 18 Jul 1999 sth...@nethelp.no wrote:
> > > Please read the documentation.
> >
> > This is hard since the actual machines and switches are almost
> > 6000 miles away from me and the last time I checked, it didn't come with
> > manuals. I know my way around the Cisco routers but the sw
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote:
> Hi ...
>
> We have previously done many network performance tests for our
> products running on FreeBSD ...
>
> We have found that when ever there is disk accessing involved, it
> is not a good idea to look at the transfer figures. We did te
At 11:40 AM 18/07/99 -0700, you wrote:
>Tim Baird wrote:
>
>> I hope everyone is benefitting by these simple facts
>
> *chuckle* "Simple facts.." You sound like my physics professor. I for
> one
>am benefitting very much from the discussion. I got hired at my current job
>as a software p
Hi ...
We have previously done many network performance tests for our
products running on FreeBSD ...
We have found that when ever there is disk accessing involved, it
is not a good idea to look at the transfer figures. We did tests
with ftp and is was slow (compared to only memory generated
On Sun, 18 Jul 1999, Jonathan M. Bresler wrote:
> > I guess I forgot about the overhead. I've tested between two
> > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL
> > Switch Full Duplex and never seen anything close to the speeds.
>
> using netperfv2pl3 an
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote:
> > > Please read the documentation.
> >
> > This is hard since the actual machines and switches are almost
> > 6000 miles away from me and the last time I checked, it didn't come with
> > manuals. I know my way around the Cisco routers but the s
At 11:40 AM 18/07/99 -0700, you wrote:
>Tim Baird wrote:
>
>> I hope everyone is benefitting by these simple facts
>
> *chuckle* "Simple facts.." You sound like my physics professor. I for one
>am benefitting very much from the discussion. I got hired at my current job
>as a software per
>
> I guess I forgot about the overhead. I've tested between two
> FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL
> Switch Full Duplex and never seen anything close to the speeds.
using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp
cards (all fro
>
> I guess I forgot about the overhead. I've tested between two
> FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL
> Switch Full Duplex and never seen anything close to the speeds.
using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp
cards (all fr
Tim Baird wrote:
> I hope everyone is benefitting by these simple facts
*chuckle* "Simple facts.." You sound like my physics professor. I for
one
am benefitting very much from the discussion. I got hired at my current job
as a software person, but I have a background in hardware so I
Tim Baird wrote:
> I hope everyone is benefitting by these simple facts
*chuckle* "Simple facts.." You sound like my physics professor. I for one
am benefitting very much from the discussion. I got hired at my current job
as a software person, but I have a background in hardware so I
> > Please read the documentation.
>
> This is hard since the actual machines and switches are almost
> 6000 miles away from me and the last time I checked, it didn't come with
> manuals. I know my way around the Cisco routers but the switches is still
> a mystery...
All of the Cisco docum
On Sun, 18 Jul 1999 sth...@nethelp.no wrote:
> > I'm not sure if it shows the mac address of the cisco's port or
> > the actual device connected to it...
> >
> > FastEthernet0/1 is up, line protocol is up
> > Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia
> > 0090.abea.3bc1)
> >
> I'm not sure if it shows the mac address of the cisco's port or
> the actual device connected to it...
>
> FastEthernet0/1 is up, line protocol is up
> Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia
> 0090.abea.3bc1)
>
> FastEthernet0/2 is up, line protocol is up
> Hardwa
On Friday, 16 July 1999 at 19:15:31 -0700, Matthew Dillon wrote:
> : Actually, I was referring to *digital* Audio cables like those
> :used for CD Transports to Digital/Analog convertors such as Kimber Kable
> :would be higher grade compared to Monster Cable. You're correct about the
> :bit er
> > Please read the documentation.
>
> This is hard since the actual machines and switches are almost
> 6000 miles away from me and the last time I checked, it didn't come with
> manuals. I know my way around the Cisco routers but the switches is still
> a mystery...
All of the Cisco docu
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote:
> > I'm not sure if it shows the mac address of the cisco's port or
> > the actual device connected to it...
> >
> > FastEthernet0/1 is up, line protocol is up
> > Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia
> > 0090.abea.3bc1)
>
> I'm not sure if it shows the mac address of the cisco's port or
> the actual device connected to it...
>
> FastEthernet0/1 is up, line protocol is up
> Hardware is Fast Ethernet, address is 0090.abea.3bc1 (bia
> 0090.abea.3bc1)
>
> FastEthernet0/2 is up, line protocol is up
> Hardw
On Sun, 18 Jul 1999, Leif Neland wrote:
> On Sat, 17 Jul 1999, Vincent Poy wrote:
>
> > Ah, you have a point there. The problem is we have so many wires,
> > we don't know which port goes to what on the Catalyst so we had it on
> > autodetect and FreeBSD does boot up with fxp0 showing 100Mbp
> > Ah, you have a point there. The problem is we have so many wires,
> > we don't know which port goes to what on the Catalyst so we had it on
> > autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex.
> >
> Cisco's can show you which mac-adresses are on which port. Proba
On Friday, 16 July 1999 at 19:15:31 -0700, Matthew Dillon wrote:
> : Actually, I was referring to *digital* Audio cables like those
> :used for CD Transports to Digital/Analog convertors such as Kimber Kable
> :would be higher grade compared to Monster Cable. You're correct about the
> :bit e
On Sat, 17 Jul 1999, Vincent Poy wrote:
> Ah, you have a point there. The problem is we have so many wires,
> we don't know which port goes to what on the Catalyst so we had it on
> autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex.
>
Cisco's can show you which ma
On Sun, 18 Jul 1999, Leif Neland wrote:
> On Sat, 17 Jul 1999, Vincent Poy wrote:
>
> > Ah, you have a point there. The problem is we have so many wires,
> > we don't know which port goes to what on the Catalyst so we had it on
> > autodetect and FreeBSD does boot up with fxp0 showing 100Mb
> > Ah, you have a point there. The problem is we have so many wires,
> > we don't know which port goes to what on the Catalyst so we had it on
> > autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex.
> >
> Cisco's can show you which mac-adresses are on which port. Prob
On Sat, 17 Jul 1999, Vincent Poy wrote:
> Ah, you have a point there. The problem is we have so many wires,
> we don't know which port goes to what on the Catalyst so we had it on
> autodetect and FreeBSD does boot up with fxp0 showing 100Mbps Full Duplex.
>
Cisco's can show you which m
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> :> 2.6 MB/sec is what I would expect if you were running the test
> :> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
> :> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
> :
> : That was actu
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> :> 2.6 MB/sec is what I would expect if you were running the test
> :> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
> :> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
> :
> : That was act
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> : Hmmm, how did you do the measurement and how big of a file does it
> :need?
> :
> : With a 122MByte file, it only does 2644Kbytes/sec. This is
> :between two Pentium II 450 machines with Intel Pro100+ NICs.
> :
> :
> :Cheers,
> :Vince - vi...
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> : Hmmm, how did you do the measurement and how big of a file does it
> :need?
> :
> : With a 122MByte file, it only does 2644Kbytes/sec. This is
> :between two Pentium II 450 machines with Intel Pro100+ NICs.
> :
> :
> :Cheers,
> :Vince - [EMA
:On 17-Jul-99 Matthew Dillon wrote:
:>
:> Obviously you don't get square waves going down the wire - But it is
:> still a digital communications protocol.
:>
:> -Matt
:
:However the physical layer, i.e. the cable, is analogue and the discussion was
:a
:> 2.6 MB/sec is what I would expect if you were running the test
:> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
:> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
:
: That was actually done with ftp between two machines connected
:F
:On 17-Jul-99 Matthew Dillon wrote:
:>
:> Obviously you don't get square waves going down the wire - But it is
:> still a digital communications protocol.
:>
:> -Matt
:
:However the physical layer, i.e. the cable, is analogue and the discussion was
:
:> 2.6 MB/sec is what I would expect if you were running the test
:> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
:> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
:
: That was actually done with ftp between two machines connected
:
Vincent Poy wrote:
> Testing after the dust has settled and while it is in use is
> different since conditions do change. The testers only tests for
> continuity, not the impedance or any other electrical properties of the
> cable.
The decent testers (such as a professional cable install
On Sat, 17 Jul 1999, Vincent Poy wrote:
> > > > As I said, I used ttcp. ttcp is a "network only" test - it can source
> > > > or sink traffic itself. This is nice because you avoid other sources of
> > > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds
> > > > to one minut
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> : Hmmm, how did you do the measurement and how big of a file does it
> :need?
> :
> : With a 122MByte file, it only does 2644Kbytes/sec. This is
> :between two Pentium II 450 machines with Intel Pro100+ NICs.
>
> 2.6 MB/sec is what I would
On Sun, 18 Jul 1999 sth...@nethelp.no wrote:
> > > As I said, I used ttcp. ttcp is a "network only" test - it can source
> > > or sink traffic itself. This is nice because you avoid other sources of
> > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds
> > > to one minute.
On Sun, 18 Jul 1999, Leif Neland wrote:
> > > There again, any network installer worth their salt will test the cable
> when
> > > in-situ, after the 'dust' has settled...
> >
> > Testing after the dust has settled and while it is in use is
> > different since conditions do change. The testers on
On 17-Jul-99 Matthew Dillon wrote:
>
> Obviously you don't get square waves going down the wire - But it is
> still a digital communications protocol.
>
> -Matt
However the physical layer, i.e. the cable, is analogue and the discussion was
about cab
1 - 100 of 176 matches
Mail list logo
