> Are you using the latest lttng-agent code (dated 2011-08-12)? This one has a
> fix for corrupted traces when streaming through the network in overload
> conditions. And it is very possible that the kernel traces produce more
> events than the network connection can handle. Even without corruption, you
> could expect a lot of missing events.

   I generated a non-Eclipse trace (using tcf-client) and it indeed has the 
same toxicity, so the problem is not with Eclipse but rather at the 
tcf/lttng-agent/lttng-client level.

   This experiment revealed yet another problem: to speed things up I decided 
to use tcf-client's -S option (which substitutes a script file to stdin).  
Here's the script (names and numbers have been anonymised):

connect TCP:131.132.133.134:1534
tcf ltt_control setupTrace "kernel" "0" "fromdutscriptofesr4ondut"
tcf ltt_control setTraceTransport "kernel" "0" "fromdutscriptofesr4ondut" 
"relay"
tcf ltt_control setChannelSubbufSize "kernel" "0" "fromdutscriptofesr4ondut" 
"all" 1048576
tcf ltt_control allocTrace "kernel" "0" "fromdutscriptofesr4ondut"
lttctl_client ltt_control writeTraceNetwork "kernel" "0" 
"fromdutscriptofesr4ondut" "/traces/fromdutscriptofesr4ondut" 2 false false 
false
tcf ltt_control startTrace "kernel" "0" "fromdutscriptofesr4ondut"

   Judging by stdout, everything worked fine:

 Connection established with TCP:131.132.32.42:1534
 "Action succeeded" 
 "relay" 
 1048576 
 "Action succeeded" 
 "Trace output path successfully set up (local to tracing controller)" 
 "Action succeeded"

   (Recall that I'm using lttng-agent/client modified with improved 
command-line user feedback)  There is a one-to-one correspondence between 
command lines in the script and output lines.  The script merely starts the 
trace; I then do some stuff on the traced machine, and then pause and destroy 
the trace manually (interactively) from another tcf-client.

   However, my destination folder ended up with just one file in it 
(irq_state_0) of size zero.  I then repeated the whole sequence using the 
tcf-client command-line interface (with the same commands from the script save 
for a different target folder) and it generated a trace just fine (albeit a 
toxic one).  I then ran the script a second time (with a third target folder) 
and it gave the same appearance of success and nearly the same actual failure 
(it fared worse, failing to create even a single file in the target folder).

   Has anyone else had success with tcf-client's -S switch?  (I'll ask this 
also on the tcf-dev mailing list)

Daniel U. Thibault
R & D pour la défense Canada - Valcartier (RDDC Valcartier) / Defence R&D 
Canada - Valcartier (DRDC Valcartier)
Système de systèmes (SdS) / System of Systems (SoS)
Solutions informatiques et expérimentations (SIE) / Computing Solutions and 
Experimentations (CSE)
2459 Boul. Pie XI Nord
Québec, QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
NAC: 918V QSDJ
Gouvernement du Canada / Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>
_______________________________________________
linuxtools-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev

Reply via email to