G'Day Darren, On Tue, Oct 10, 2006 at 03:21:40PM -0700, [EMAIL PROTECTED] wrote: [...] > > # ./tcpio2.d > > LADDR:PORT RADDR:PORT BYTES FLAGS > > 192.168.1.185:79 <- 192.168.1.109:56145 0 (SYN) > > 192.168.1.185:79 -> 192.168.1.109:56145 0 (SYN|ACK) > > 192.168.1.185:79 <- 192.168.1.109:56145 0 (ACK) > > 192.168.1.185:79 <- 192.168.1.109:56145 2 (PUSH|ACK) > > 192.168.1.185:79 -> 192.168.1.109:56145 0 (ACK) > > 192.168.1.185:79 -> 192.168.1.109:56145 126 (PUSH|ACK) > > 192.168.1.185:79 <- 192.168.1.109:56145 0 (ACK) > > 192.168.1.185:79 -> 192.168.1.109:56145 0 (FIN|ACK) > > 192.168.1.185:79 <- 192.168.1.109:56145 0 (ACK) > > 192.168.1.185:79 <- 192.168.1.109:56145 0 (FIN|ACK) > > 192.168.1.185:79 -> 192.168.1.109:56145 0 (ACK) > > > > Is this, by itself, a worthwhile goal of dtrace's TCP provider? > Why would I care to use dtrace for this when snoop/tcpdump does it?
Noone said it was a worthwhile goal. This output is from the CEC 2006 demonstration, and was used to demonstrate some of the capabilities of the provider. Which it does nicely. It demonstrates that one can acess IP and TCP information with the rich programming functionality and low performance costs of DTrace. No, it doesn't show why the provider trumps snoop - so perhaps you are right, and I shouldn't copy-n-paste it as demonstration #1. > Or to put it differently, I'd never use dtrace for this task and > I'd never suggest/recommend anyone use it for this task either. > In my mind it is (and will always be) the wrong tool for this > particular job. Such a snoop like output is supposed to trigger the imagination for what customisations and enhancements one can make with the DTrace programming language. > Show me something I can't do with tcpdump/snoop...examining loopback > traffic on Solaris is interesting, but there's a good chance that the > IP observability project will deliver this before dtrace. How about snoop without the performance cost, # prstat PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 1835 nobody 2456K 1640K sleep 41 0 0:01:39 51% snoop/1 1838 root 2360K 944K run 53 0 0:00:20 11% rsh/1 1836 root 2108K 1868K sleep 59 0 0:00:09 4.9% dd/1 744 brendan 216M 194M run 59 0 2:33:39 1.2% Xorg/1 1875 brendan 142M 120M sleep 49 0 0:29:54 0.7% opera/2 That was a "snoop -rs64" on a busy single NIC host. Good thing it didn't have busy apps - as application performance may well suffer with snoop wanting 51% CPU. Anyhow - I don't want to make this about why snoop may be bad, it's more about what we can do with the provider, what we can solve, and what new performance metrics we can create. > >And tcpaccept2.d aggregates inbound connections by hostname and > >service name, > > > > # ./tcpaccept2.d > > dtrace: script './tcpaccept2.d' matched 1 probe > > Tracing... Hit Ctrl-C to end. > > ^C > > HOSTNAME PORT COUNT > > marlin6 finger 1 > > bass login 2 > > marlin ssh 2 > > marlin telnet 2 > > marlin finger 3 > > > > I find this a more interesting demonstration of dtrace and TCP. > > Can you tell me the average lifespan of each connection? > And that per-host? Great idea (and it rings a bell - customers have asked me this before) - I've added it to the website (actual screenshots), http://www.opensolaris.org/os/community/dtrace/NetworkProvider/#tcp18 # ./tcplifespan1.d ^C Inbound Connection Lifespan Report (ms), deimos http value ------------- Distribution ------------- count 1 | 0 2 |@@@@@@@@@@@@@@@@@@@@@@@ 7 4 |@@@@@@@@@@ 3 8 |@@@ 1 16 | 0 32 |@@@ 1 64 | 0 deimos finger value ------------- Distribution ------------- count 8 | 0 16 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 4 32 |@@@@@@@@ 1 64 | 0 deimos ssh value ------------- Distribution ------------- count 2048 | 0 4096 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ 1 8192 | 0 I wrote varients which I haven't put on the website yet, including, # ./tcplifespan2.d Tracing... Hit Ctrl-C to end. ^C Inbound Connection Lifespan Report, HOSTNAME PORT AVG(ms) MAX(ms) COUNT deimos http 3 4 3 deimos finger 40 56 3 deimos ssh 2238 2238 1 > What about for http, can you tell me the number of connections > my web server gets for each host, on average how long each one > takes (from accept to close) and the average number of bytes > sent by TCP? Yes - I should add a bytes column to tcplifespan2.d. :) These are good questions - customers have asked me for such metrics before, and they are the exact type of questions that the provider will answer best. cheers, Brendan -- Brendan [CA, USA] _______________________________________________ networking-discuss mailing list [email protected]
