David Hagel <[EMAIL PROTECTED]> writes:
> Would there be any data out there on what fraction from this 60ms to
> 80ms RTT is raw propagation delay and what fraction is typical packet
> queuing delay at intermediate switches? Does queuing delay play much
> of a role at all these days? Or is it al
Anyone have a contact at Mpower who can work on routing issues outside
the hours of 9 to 5 Mon - Fri?
Thanks.
On Sun, 21 Aug 2005 18:38:32 PDT, David Hagel said:
> Would there be any data out there on what fraction from this 60ms to
> 80ms RTT is raw propagation delay and what fraction is typical packet
> queuing delay at intermediate switches? Does queuing delay play much
> of a role at all these days? O
Richard,
Thanks for the highly informative answer.
Would there be any data out there on what fraction from this 60ms to
80ms RTT is raw propagation delay and what fraction is typical packet
queuing delay at intermediate switches? Does queuing delay play much
of a role at all these days? Or is it
On Sun, Aug 21, 2005 at 07:13:39PM -0400, David Hagel wrote:
>
> I was wondering what are the typical coast-to-coast propagation and
> queuing delays observed by today's backbone networks in North America.
> Is there any data/study which provides a breakdown of different
> components of such end-
I was wondering what are the typical coast-to-coast propagation and
queuing delays observed by today's backbone networks in North America.
Is there any data/study which provides a breakdown of different
components of such end-to-end delays in today's backbone networks?
Thanks,
David
Steve Brown wrote:
Perhaps they are referring to being able to vary the speed while it is
below the speed of light. That is, slowing it down to 1/10th the speed
of light, and then speeding it up to 1/5th the speed of light.
Steve Brown
I have had a look into one of my microwave books. I
(hoping this is still somewhat ontopic, should be much more ontopic than my
last reply was)
Robert Bonomi wrote:
Authoritative answer: "Maybe."
Usually.
Depends on the locale, the state regulators, and the phone company.
Frequently called "Lifeline" service, when marketed for the elderl
Okay, guess I should have read the article first, given the title is "Light
that travels faster than the speed of light"
Steve
Perhaps they are referring to being able to vary the speed while it is
below the speed of light. That is, slowing it down to 1/10th the speed of
light, and then s
Perhaps they are referring to being able to vary the speed while it is below
the speed of light. That is, slowing it down to 1/10th the speed of light,
and then speeding it up to 1/5th the speed of light.
Steve Brown
- Original Message -
From: "Fergie (Paul Ferguson)" <[EMAIL PROTEC
In case no one else has suggested it: the source MAC address will
identify the source.
Chris
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Scott Morris
> Sent: Sunday, August 21, 2005 9:21 AM
> To: 'Tom Sanders'; [EMAIL PROTECTED]
> Subject: RE
How about the source IP?
RIP v1 is sent to 255.255.255.255 broadcast. RIPv2 is sent to 224.0.0.9
multicast. Both are local-link only, so won't go THROUGH a router. The
sending source IP will tell you where they came from.
If you're using VLANs (trunks), there won't be any issues. If you're u
Hi,
There isnt IMO a way in RIP to identify the source of the RIP packet
(the way we have Router ID in OSPF, system ID in ISIS, etc.)
Now assume we have 2 vlans defined on an ethernet. Thus we would have
two IP interfaces, 1.1.1.1/24 and 2.2.2.2/24 and both using the same
physical interface. RIP
Hank Nussbacher wrote:
On Sat, 20 Aug 2005, Fergie (Paul Ferguson) wrote:
I doubt they are exceeding the speed of light. Propogation delay inside
fiber is about 2/3 the speed of light so perhaps they have succeeded to
increase the speed to 3/4? :-)
-Hank
I have seen experiments with antenna
14 matches
Mail list logo
