Correction....

limitations issues occur at the transceiving limit

should read:

limitation issues occur at the transceiving nodes


Jonathan L. Raper, A+, MCSA, MCSE
Technology Coordinator
Eagle Physicians & Associates, PA
[email protected]<BLOCKED::mailto:%[email protected]>
www.eaglemds.com<BLOCKED::http://www.eaglemds.com/>

________________________________
From: Raper, Jonathan - Eagle [mailto:[email protected]]
Sent: Tuesday, November 16, 2010 9:41 AM
To: NT System Admin Issues
Subject: RE: Otish Acceptable network QOS

IMNSHO, that spec is waaaaaay too forgiving. IME, fiber either works or it 
doesn't, and limitations issues occur at the transceiving limit or on 
intermediate routers/switches between endpoints. What is the distance of the 
fiber being run, and is it multimode or singlemode? How many microns? Based on 
your email it sounds like this will be dark fiber, but I don't like to assume - 
is that the case, or will these be leased lines?

Is that RFP assuming a ping of 32 bytes or something else? In my environment, 
if I run a continuous ping using a send buffer size of 50,000 bytes (yes, fifty 
thousand) the response times will look significantly different than when I send 
a standard ping which only uses a send buffer size of 32 bytes. To put things 
into perspective, I also have 10 Mb FDX leased lines (layer 2 MetroE) from my 
data center to a handful of my sites. When I ping with a standard send buffer, 
I get on AVERAGE 1 millisecond response times. If I bump that up to 1500 bytes, 
then my response time jumps to 4ms.

I have dark fiber as well as Free Space Optics point to point (operating at 
both 100 Mb FDX as well as GigE), and I NEVER see greater than 5ms unless there 
is an issue with the equipment on either end. The norm is for me to see 
sub-millisecond response time for a standard ping, and I'm passing high 
resolution images across my WAN as well as textual data.

Jonathan L. Raper, A+, MCSA, MCSE
Technology Coordinator
Eagle Physicians & Associates, PA
[email protected]<BLOCKED::mailto:%[email protected]>
www.eaglemds.com<BLOCKED::http://www.eaglemds.com/>

________________________________
From: Kennedy, Jim [mailto:[email protected]]
Sent: Tuesday, November 16, 2010 8:39 AM
To: NT System Admin Issues
Subject: Otish Acceptable network QOS


Ok, we are putting out a request for proposals to upgrade/redo our links 
between our buildings.  We have 100 MB fiber between our locations dedicated to 
us, we are ramping up to gig.  Right now I can ping a server or anything else 
around town with 1 ms delays and we never see packet loss. We are using an 
outside school consultant to help write the RFP. One thing he came up with 
caught my eye and I thought I would get the collectives opinion on it.

Understand that as a public school these RFP's are our bibles. What is in them 
is exactly what the vendor is held to, no more no less. So if it isn't right 
later on the vendor will just shrug and point to the RFP. I am not too keen on 
writing in an allowed 50 ms delay and .5% packet loss on dedicated fiber to my 
buildings. Especially when I have no issues like that at 100 MB. Thoughts gang?



The maximum round trip delays / latency between any source/destination site 
shall be no greater than 50 milliseconds (ms). The acceptable tolerance range 
for jitter on the WAN will be no greater than 25ms and the packet loss will be 
less than 0.5%. The measurement of these metrics will be between the CPEs at 
the source and destination sites.

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to 
[email protected]<mailto:[email protected]>
with the body: unsubscribe ntsysadmin

________________________________
Any medical information contained in this electronic message is CONFIDENTIAL 
and privileged. It is unlawful for unauthorized persons to view, copy, 
disclose, or disseminate CONFIDENTIAL information. This electronic message may 
contain information that is confidential and/or legally privileged. It is 
intended only for the use of the individual(s) and/or entity named as 
recipients in the message. If you are not an intended recipient of this 
message, please notify the sender immediately and delete this material from 
your computer. Do not deliver, distribute or copy this message, and do not 
disclose its contents or take any action in reliance on the information that it 
contains.

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to 
[email protected]<mailto:[email protected]>
with the body: unsubscribe ntsysadmin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

---
To manage subscriptions click here: 
http://lyris.sunbelt-software.com/read/my_forums/
or send an email to [email protected]
with the body: unsubscribe ntsysadmin

Reply via email to