[103427] in North American Network Operators' Group
RE: latency (was: RE: cooling door)
daemon@ATHENA.MIT.EDU (Fred Reimer)
Sun Mar 30 12:12:38 2008
Date: Sun, 30 Mar 2008 12:11:40 -0400
In-Reply-To: <g3fxu8ffgo.fsf@sa.vix.com>
From: "Fred Reimer" <freimer@ctiusa.com>
To: "Paul Vixie" <vixie@isc.org>, <nanog@merit.edu>
Errors-To: owner-nanog@merit.edu
This is a multipart message in MIME format.
------=_NextPart_000_0008_01C8925F.35C328F0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
> -----Original Message-----
> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of
> Paul Vixie
> Sent: Sunday, March 30, 2008 10:35 AM
> To: nanog@merit.edu
> Subject: Re: latency (was: RE: cooling door)
>
>
> swmike@swm.pp.se (Mikael Abrahamsson) writes:
>
> > Programmers who do client/server applications are starting to notice
> this
> > and I know of companies that put latency-inducing applications in the
> > development servers so that the programmer is exposed to the same
> > conditions in the development environment as in the real world. This
> > means for some that they have to write more advanced SQL queries to
> get
> > everything done in a single query instead of asking multiple and
> changing
> > the queries depending on what the first query result was.
>
> while i agree that turning one's SQL into transactions that are more
> like
> applets (such that, for example, you're sending over the content for a
> potential INSERT that may not happen depending on some SELECT, because
> the
> end-to-end delay of getting back the SELECT result is so much higher
> than
> the cost of the lost bandwidth from occasionally sending a useless
> INSERT)
> will take better advantage of modern hardware and software architecture
> (which means in this case, streaming), it's also necessary to teach our
> SQL servers that ZFS "recordsize=128k" means what it says, for file
> system
> reads and writes. a lot of SQL users who have moved to a streaming
> model
> using a lot of transactions have merely seen their bottleneck move from
> the
> network into the SQL server.
I have seen first hand (worked for a company and diagnosed issues with their
applications from a network perspective, prompting a major re-write of the
software), where developers work with their SQL servers, application
servers, and clients all on the same L2 switch. They often do not duplicate
the environment they are going to be deploying the application into, and
therefore assume that the "network" is going to perform the same. So, when
there are problems they blame the network. Often the root problem is the
architecture of the application itself and not the "network." All the
servers and client workstations have Gigabit connections to the same L2
switch, and they are honestly astonished when there are issues running the
same application over a typical enterprise network with clients of different
speeds (10/100/1000, full and/or half duplex). Surprisingly, to me, they
even expect the same performance out of a WAN.
Application developers today need a "network" guy on their team. One who
can help them understand how their proposed application architecture would
perform over various customer networks, and that can make suggestions as to
how the architecture can be modified to allow the performance of the
application to take advantage of the networks' capabilities. Mikael (seems
to) complain that developers have to put latency inducing applications into
the development environment. I'd say that those developers are some of the
few who actually have a clue, and are doing the right thing.
> > Also, protocols such as SMB and NFS that use message blocks over TCP
> have
> > to be abandonded and replaced with real streaming protocols and large
> > window sizes. Xmodem wasn't a good idea back then, it's not a good
> idea
> > now (even though the blocks now are larger than the 128 bytes of 20-
> 30
> > years ago).
>
> i think xmodem and kermit moved enough total data volume (expressed as
> a
> factor of transmission speed) back in their day to deserve an
> honourable
> retirement. but i'd agree, if an application is moved to a new
> environment
> where everything (DRAM timing, CPU clock, I/O bandwidth, network
> bandwidth,
> etc) is 10X faster, but the application only runs 2X faster, then it's
> time
> to rethink more. but the culprit will usually not be new network
> latency.
> --
> Paul Vixie
It may be difficult to switch to a streaming protocol if the underlying data
sets are block-oriented.
Fred Reimer, CISSP, CCNP, CQS-VPN, CQS-ISS
Senior Network Engineer
Coleman Technologies, Inc.
954-298-1697
------=_NextPart_000_0008_01C8925F.35C328F0
Content-Type: application/x-pkcs7-signature;
name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="smime.p7s"
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII0jCCAlow
ggHDoAMCAQICEE/N8u+Cjf1akAnPH3Rf2m8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx
JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ
ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDEyMjIxMjcyN1oXDTA5MDEyMTIxMjcy
N1owRDEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYSZnJl
aW1lckBjdGl1c2EuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDFAAtjFvwayIA70SOY
SunlDptyQhb1DviV+LHKOcX5MadLk2NANpODodUvSUb2AgwAqOkCv7cEEMVTAtYaupWbqtyTSTC8
/T8+mmKwBFgci1PmQrkfE30vneHVuylH2n/lKE4vbLXDFKpcIvqSE8SkgAxQFF2+npog2Uxase9t
6QIDAQABoy8wLTAdBgNVHREEFjAUgRJmcmVpbWVyQGN0aXVzYS5jb20wDAYDVR0TAQH/BAIwADAN
BgkqhkiG9w0BAQUFAAOBgQAHcmBSgreS/FopWMmY+jGgR8IMk07AxNIyvszC1+EqT5GN8CB+BOrr
ePcfIajM/1s/jVJhl7GN/wbKx39vcRFLdTMWfYwRWXJfJFk9C7NBp5QmpUaVxi/q0BFTC9l25BnB
13sv24vIsjSCGif979xFZpwEdP+UZ4U9xfqG+Ps32jCCAy0wggKWoAMCAQICAQAwDQYJKoZIhvcN
AQEEBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRp
b24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBD
QTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw05NjAxMDEw
MDAwMDBaFw0yMDEyMzEyMzU5NTlaMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBD
YXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYD
VQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVy
c29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANRp19SwlGRbcelH2AxRtupykbCEXn0t
DY97Et+FJXUodDpCLGMnn5V7S+9+GYcdhuqj3bnOlmQawhRuRKx85o/oTQ9xH0A4pgCjh3j2+ZSG
Xq3qwF5269kUo11uenwMpUtVfwYZKX+emibVars4JAhqmMex2qOYkf152+VaxBy5AgMBAAGjEzAR
MA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEEBQADgYEAx+ySfk749ZalZ2IqpPBNEWDQb41g
WGGsJrtSNVwIzzD7qEqWih9iQiOMFw/0umScF6xHKd+dmF7SbGBxXKKs3Hnj524ARx+1DSjoAp3k
mv0T9KbZfLH43F8jJgmRgHPQFBveQ6mDJfLmnC8Vyv6mq4oHdYsM3VGEa+T40c53ooEwggM/MIIC
qKADAgECAgENMA0GCSqGSIb3DQEBBQUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVy
biBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgw
JgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUg
UGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRo
YXd0ZS5jb20wHhcNMDMwNzE3MDAwMDAwWhcNMTMwNzE2MjM1OTU5WjBiMQswCQYDVQQGEwJaQTEl
MCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBl
cnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMSm
PFVzVftOucqZWh5owHUEcJ3f6f+jHuy9zfVb8hp2vX8MOmHyv1HOAdTlUAow1wJjWiyJFXCO3cnw
K4Vaqj9xVsuvPAsH5/EfkTYkKhPPK9Xzgnc9A74r/rsYPge/QIACZNenprufZdHFKlSFD0gEf6e2
0TxhBEAeZBlyYLf7AgMBAAGjgZQwgZEwEgYDVR0TAQH/BAgwBgEB/wIBADBDBgNVHR8EPDA6MDig
NqA0hjJodHRwOi8vY3JsLnRoYXd0ZS5jb20vVGhhd3RlUGVyc29uYWxGcmVlbWFpbENBLmNybDAL
BgNVHQ8EBAMCAQYwKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDItMTM4MA0G
CSqGSIb3DQEBBQUAA4GBAEiM0VCD6gsuzA2jZqxnD3+vrL7CF6FDlpSdf0whuPg2H6otnzYvwPQc
UCCTcDz9reFhYsPZOhl+hLGZGwDFGguCdJ4lUJRix9sncVcljd2pnDmOjCBPZV+V2vf3h9bGCE6u
9uo05RAaWzVNd+NWIXiC3CEZNd4ksdMdRv9dX2VPMYIC+DCCAvQCAQEwdjBiMQswCQYDVQQGEwJa
QTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3Rl
IFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEE/N8u+Cjf1akAnPH3Rf2m8wCQYFKw4DAhoF
AKCCAdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMzMwMTYx
MTQwWjAjBgkqhkiG9w0BCQQxFgQU19yC4mKsV/QZO7kQS1SuS2LDNTMwZwYJKoZIhvcNAQkPMVow
WDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwBwYFKw4DAhowCgYIKoZIhvcNAgUwgYUGCSsGAQQBgjcQBDF4MHYwYjELMAkG
A1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT
I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhBPzfLvgo39WpAJzx90X9pvMIGH
BgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0
aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n
IENBAhBPzfLvgo39WpAJzx90X9pvMA0GCSqGSIb3DQEBAQUABIGAiqARXGvOgZU9ONknipa5dKFS
XoS8Z1ApGXwVxxFtOuh1/7F5TX+GcBF7+urZOps7Yc9+Ktu0Wq08b4scM6vGrQdW+Lncmqwf4fnf
BkD782nleUyZ/OUBEJ2wOZt6m7RjIIQM8m3wVyFHOBGl/QZBSOcFjxQRYAqwTgx+FIPK/bcAAAAA
AAA=
------=_NextPart_000_0008_01C8925F.35C328F0--
