olg33 writes: >> Where are you getting these values from? Tcpdump? The labels are not sent on the wire at all (and nothing you can do to change that). > >> The 'labels' parameter should set the plot labels on the Flent plots, though... > > It's Wireshark and I'm only showing the relevant information. Ok good to know, the labels are just for displaying purpose, in fact I'm not too worried about the labels as I'm feeding the output to Netdata for graphing. > > My main concern is that (at least for me) the new MARKING_MAP doesn't seem to be working. > MARKING_MAP = { > '10': 0x28, > '11': 0x2c, > '13': 0x34, > '15': 0x38, > '17': 0x40, > '19': 0x4c, > '20': 0x50, > '21': 0x54, > '23': 0x5c, > '25': 0x64, > '27': 0x6c, > '29': 0x74} > If I run the following test (after editing the MARKING_MAP with custom settings): > >> ./run-flent rrul_var --test-parameter bidir_streams=5 --test-parameter markings=10,13,15,17,19 -H 192.168.9.13 -l 60 > > I only see packets marked with Hex values that are not part of the map: > >> Differentiated Services Field: 0x08 (DSCP: Unknown, ECN: Not-ECT) > Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT) > Differentiated Services Field: 0x0c (DSCP: Unknown, ECN: Not-ECT) Ohh, right, the markings_map is only used for irtt and iperf, for netperf the values are just passed directly through. Totally forgot about that. I guess I could fix that, but TBH I'm not terribly keen on supporting non-standard diffserv markings in this way. You could do this yourself, though; if you replace this line in NetperfDemoRunner (in runners.py): args['marking'] = "-Y {0}".format(args['marking']) with: args['marking'] = self.parse_marking(args['marking'], "-Y {0}") that should do the trick. You'll lose the support for different markings on downstream and upstream, but that won't work with the 'markings' test parameter anyway :) > That's why I do believe I'm doing something wrong or maybe there was > an additional step other than just editing the Marking_Map. > > In fact, using just the hex values works for me, but if someone else > that only knows the custom dscp values want to test, that will fail, > that's why I'd like to be able to feed those values. Just checking, but when you say "someone else" you mean someone else who has access to that same system, right? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/tohojo/flent/issues/203#issuecomment-620800380