similar to: Understand the dtrace quantize output

Hello Srikant - A quantization distributes the results of your aggregation into ranges ordered by a power-of-two. Presumably what you''d do in your script is capture the inclusive elapsed time of each function call in your library, then use this quantization to see how tightly-banded the times are. Perhaps there''s some blocking I/O in some of your calls, for example, in which

i am doing reads and writes to /dev/rdsk/c0t2d0s4 using dtrace to see how much time it took for ssdread and ssdwrite. It shows very small number 4 or 5. #pragma D option flowindent syscall::pread:entry { self->trace = 1; self->size = arg2; } syscall::pwrite:entry { self->trace = 1; self->size = arg2; } fbt:ssd:ssdread:entry /self->trace/ { self->start = timestamp;

hi, I am trying to find out the avg cpu time spent in each of my user methods (exclusive of other methods invoked by a method). Hence the following snippet failed miserably: ----------------------- pid$target:a.out::entry { time[probefunc] = timestamp;} pid$target:a.out::return { @spent[probefunc] = avg(timestamp - time[probefunc]);} END { printa(@spent);}

We are using following dtrace script to analyze an application. However we see different number of lwp_yield and yield calls reported depending on whether we trace mutex_lock or mutex_unlock or not. The number reported when we are not tracing mutex_lock or mutex_unlock is higher. What could be going on here and which one is the correct number. This is on S10 U2. Thanks, Rao.

Whilst trying out some D to get an insight into what is the most common reason for a given function to return, I have bumped into an error I don''t understand. The first take on what I was trying to do was: # dtrace -n ''fbt:ip:ip_input:return{@home[arg0] = count();}'' and all was well. The next step was: # dtrace -n

[Perhaps someone could rename this list to dtrace-matt-problems-discuss?] If I run this script against my binary (which contains a USDT probe called ''concurrentq-latency''): ::: / probename == "concurrentq-latency" / { printf("[%s]:[%s]:[%s]\n", probeprov, probefunc, probename); } I get this output: dtrace: script ''testq.d'' matched 46056

Hello, I''m using the below dtrace script to capture the flow and times of kernel functions, from an ioctl() call. After an entry into restorectx(), the trace of startimestamp - vtimestamp makes a dramatic jump downwards. Here''s the snippet showing the jump... 6 -> di_checkmem 8 220176600 6 <- di_checkmem

[1] Predicates in one-liners I would like to list the probe modules in my executable and then dynamically create a dscript to trace execution of those modules alone (by excluding the 3rd party and system libraries). I tried the below script without success. The conditional given in the predicate is not taking effect. Why is this so ? $ dtrace -ln ''pid$target:::

Hello! I just noticed how the LPC prediction is quantized by browsing the source code of the java port jFlac: : int sum = 0; for (int j = 0; j < order; j++) sum += qlpCoeff[j] * data[startAt+i-j-1]; data[startAt + i] = residual[i] + (sum >> lpQuantization); : I checked the C version (libFLAC) and it matches. However, it was a surprise because this way of quantizing the

1) What are you doing "mathematically" in a procedure x86/x86enquant: oc_enc_quantize_sse2()? This - the assembler code, and I do not understand mathematically - that's going on there. --- A: 120 121 28 73 -20 -99 -98 -100 123 122 112 108 73 -32 -102 -98 123 123 117 121 100

I''m wondering if I should file a bug against this or is this just a case of a user doing something stupid :) I ran the following script on my desktop: #!/usr/sbin/dtrace -s pid9276:::entry { @counting[probefunc] = count(); } And my Xsession immediately crashed and through me back to the login screen. My OS is 5.11 snv_50 i86pc i386 i86pc with a dual core amd chip and 2G or

Hello all, I saw this question about a year back in the archive[1], but with no final answer. I would like to trace shmget calls and also get the id of the shared memory segment. That script looked like[2], but we dont get the id since arg1 is the errno value. How do i access the shm id, i would need this to debug a customer problem but i don''t have time to learn it the hard

Just showing someone how great DTrace is and then we spot something I do not understand. Of course it can be a major misunderstanding of myself. Would appreciate another (expert) look upon this. The goal we try to achieve is trying to get insight if there is a bursty nature in the time slot when system calls are done. Following DTrace snippet is tried: dtrace -q -p 3173 -n

(PS: another idea that comes along the same lines as a dumper function and IMO would be helpful is an ''introspect'' function. Given an argument: introspect(probefunc) it returns back the expected arguments for the probe func, their datastructures, as well as the syntax on how to dereference them. If an intelligent copyinstr comes out, this would be easy to write, and would

everyone Here: How do you do! dtrace is interesting. I am studing how to write dtrace script and analyze situation. I read dtrace_example.pdf and 819-6959.pdf document more than five times with careful. because I am newbie to studing dtrace.so I still don''t know how to begin. for question: 1. What consumes time? 2. Which system call(s) consume(s) time?

Hopefully this is a straight forward issue and I''m missing something obvious. I''m trying to print a wchar_t [] argument from a simple example program like #include <stdio.h> #include <wchar.h> #include <unistd.h> void prout(wchar_t *wstr) { } int main() { wchar_t name[]=L"Angelo Rajadurai"; int i; for(i=0; i<1000 ; i++) { prout(name);

I wrote a simple c programme and do some dtrace test. the progromme shows below(write.c): /////////////////////////////// #include<stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> char *value="hello,my name is wanjm\n"; void main() { int fd; fd=open("/export/home/wanjm/temp/read.txt",O_RDWR|O_CREAT); while(1) {

Recently I found that the mac_srs_rx_poll_ring thread may never stop in kernel, please see the following mpstat, cpu 2 is in 100% kernel usage, but no syscalls and no interrupts. CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl 0 0 0 0 300 100 0 0 1 0 0 0 0 0 0 100 1 14 0 0 134 68 134 1

A user has asked us to find out who is changing one of their files and how it is being changed. I came up with the script below: #!/usr/sbin/dtrace -s #pragma D option quiet BEGIN { printf("\n Timestamp gid uid pid ppid execname function current directory file name\n\n"); } syscall::open:entry,

everyone, Just out of curiosity, I did a dtrace -n ''syscall:::entry { @num[execname, probefunc] = count(); }'' and looked at the entries produced by ''rm''. I see everything that rm did, *except* the unlinkat - which is unfortunate because I want to trace which processes have deleted which files. So - does dtrace contain unlinkat as a probe for a system call?