A little better spacing seems feasible on the tc output about sch_cake

[dtaht]

I imagine @tohojo would complain if I made bytes format to an extension of b,k,etc. But it needs to be wider.... Why is requeues repeated? Could total marks get stuck into the main stanza?

[tohojo]

Dave Täht <[email protected]> writes:

I imagine @tohojo would complain if I made bytes format to an extension of b,k,etc.

Don't so much care *what* the format is, as much as the fact that it changes all the time. What happened to not breaking userspace? The Flent parser currently understands 'Kbit' and 'Mbit', but not 'k' and 'm' suffixes.

…

-Toke

[ldir-EDB0]

"changes all the time. What happened to not breaking userspace?"

Well it's not bl**dy me....this time :-)

[dtaht]

Not break userspace/kernel APIs. Breaking userspace to userspace apis is ok. My problem was and remains after enough traffic the output bleeds together for bytes. which probably breaks flent anyway.

[tohojo]

Dave Täht <[email protected]> writes:

Not break userspace/kernel APIs. Breaking userspace to userspace apis is ok.

That seems somewhat arbitrary, but OK...

My problem was and remains after enough traffic the output bleeds together for bytes. which probably breaks flent anyway.

I think a better solution would be one of (or both): - Increase the column width - Make sure there's always a single space between columns even if they overflow. This way, only visual alignment is lost, not parsing. Adding suffixes instead loses precision in parsing (most of the Flent plots will plot changes between subsequent samples, and if you're only accounting megabytes that gets you zero-values in many cases).

…

-Toke

[moeller0]

On Jan 29, 2017, at 14:52, Toke Høiland-Jørgensen ***@***.***> wrote: Dave Täht ***@***.***> writes: > Not break userspace/kernel APIs. Breaking userspace to userspace apis > is ok. That seems somewhat arbitrary, but OK... > My problem was and remains after enough traffic the output bleeds > together for bytes. which probably breaks flent anyway. I think a better solution would be one of (or both): - Increase the column width - Make sure there's always a single space between columns even if they overflow. This way, only visual alignment is lost, not parsing.

This, except use ; as separator (and always even when there are enough whitespaces to make the separation clear) Best Regards

…

Adding suffixes instead loses precision in parsing (most of the Flent plots will plot changes between subsequent samples, and if you're only accounting megabytes that gets you zero-values in many cases). -Toke — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[tohojo]

moeller0 <[email protected]> writes:

> On Jan 29, 2017, at 14:52, Toke Høiland-Jørgensen ***@***.***> wrote: > > Dave Täht ***@***.***> writes: > > > Not break userspace/kernel APIs. Breaking userspace to userspace apis > > is ok. > > That seems somewhat arbitrary, but OK... > > > My problem was and remains after enough traffic the output bleeds > > together for bytes. which probably breaks flent anyway. > > I think a better solution would be one of (or both): > > - Increase the column width > - Make sure there's always a single space between columns even if they > overflow. This way, only visual alignment is lost, not parsing. This, except use ; as separator (and always even when there are enough whitespaces to make the separation clear)

Why? I'd rather just use whitespace. Using semicolons would break with the current layout (and probably not look very good) and be a change in itself that would break parsing...

…

-Toke

[moeller0]

Hi Toke,

On Jan 29, 2017, at 16:00, Toke Høiland-Jørgensen ***@***.***> wrote: moeller0 ***@***.***> writes: >> On Jan 29, 2017, at 14:52, Toke Høiland-Jørgensen ***@***.***> wrote: >> >> Dave Täht ***@***.***> writes: >> >> > Not break userspace/kernel APIs. Breaking userspace to userspace apis >> > is ok. >> >> That seems somewhat arbitrary, but OK... >> >> > My problem was and remains after enough traffic the output bleeds >> > together for bytes. which probably breaks flent anyway. >> >> I think a better solution would be one of (or both): >> >> - Increase the column width >> - Make sure there's always a single space between columns even if they >> overflow. This way, only visual alignment is lost, not parsing. > > This, except use ; as separator (and always even when there are enough > whitespaces to make the separation clear) Why? I'd rather just use whitespace. Using semicolons would break with the current layout (and probably not look very good) and be a change in itself that would break parsing…

But which whitespace, spaces, tabs non-breaking spaces, inquiring minds want to know? I realize that this is a bout taste, but I am certain everybody will agree that my preferred hue will make this bike-shed most beautiful ;) When writing small adhoc text parsers I always am happier with explicit “out of band” separators that are easy to parse by simply looking at the output, a semi-colon for example seems fine, since it is not used in the current out put and hence out of line and it is unambiguously a semi-colon, while a single white space might be a blank, a non-breaking blank or a tab that happens to only have 1 position of padding. I know I am simple minded, but jest separating the columns on “;” seems neater to me? (And in case this will come up, I do not believe that JSON is an answer to the question how to make it easy to screen scrape from pretty putput, but I might be alone in considering the output subject to makeshift ad-hoc parsing...) Best Regards

…

-Toke — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[tohojo]

moeller0 <[email protected]> writes:

Hi Toke, > On Jan 29, 2017, at 16:00, Toke Høiland-Jørgensen ***@***.***> wrote: > > moeller0 ***@***.***> writes: > > >> On Jan 29, 2017, at 14:52, Toke Høiland-Jørgensen ***@***.***> wrote: > >> > >> Dave Täht ***@***.***> writes: > >> > >> > Not break userspace/kernel APIs. Breaking userspace to userspace apis > >> > is ok. > >> > >> That seems somewhat arbitrary, but OK... > >> > >> > My problem was and remains after enough traffic the output bleeds > >> > together for bytes. which probably breaks flent anyway. > >> > >> I think a better solution would be one of (or both): > >> > >> - Increase the column width > >> - Make sure there's always a single space between columns even if they > >> overflow. This way, only visual alignment is lost, not parsing. > > > > This, except use ; as separator (and always even when there are enough > > whitespaces to make the separation clear) > > Why? I'd rather just use whitespace. Using semicolons would break with > the current layout (and probably not look very good) and be a change in > itself that would break parsing… But which whitespace, spaces, tabs non-breaking spaces, inquiring minds want to know?

Any, or all, of the above. We are delimiting numbers here, so any whitespace character is unambiguously a delimiter. Just split on one or more whitespace characters, without caring which ones. Which, incidentally, is what Python's split() does by default: https://docs.python.org/2/library/stdtypes.html#str.split

…

-Toke

[moeller0]

Hi Toke,

On Jan 29, 2017, at 16:15, Toke Høiland-Jørgensen ***@***.***> wrote: moeller0 ***@***.***> writes: > Hi Toke, > >> On Jan 29, 2017, at 16:00, Toke Høiland-Jørgensen ***@***.***> wrote: >> >> moeller0 ***@***.***> writes: >> >> >> On Jan 29, 2017, at 14:52, Toke Høiland-Jørgensen ***@***.***> wrote: >> >> >> >> Dave Täht ***@***.***> writes: >> >> >> >> > Not break userspace/kernel APIs. Breaking userspace to userspace apis >> >> > is ok. >> >> >> >> That seems somewhat arbitrary, but OK... >> >> >> >> > My problem was and remains after enough traffic the output bleeds >> >> > together for bytes. which probably breaks flent anyway. >> >> >> >> I think a better solution would be one of (or both): >> >> >> >> - Increase the column width >> >> - Make sure there's always a single space between columns even if they >> >> overflow. This way, only visual alignment is lost, not parsing. >> > >> > This, except use ; as separator (and always even when there are enough >> > whitespaces to make the separation clear) >> >> Why? I'd rather just use whitespace. Using semicolons would break with >> the current layout (and probably not look very good) and be a change in >> itself that would break parsing… > > But which whitespace, spaces, tabs non-breaking spaces, inquiring > minds want to know? Any, or all, of the above. We are delimiting numbers here, so any whitespace character is unambiguously a delimiter. Just split on one or more whitespace characters, without caring which ones. Which, incidentally, is what Python's split() does by default: https://docs.python.org/2/library/stdtypes.html#str.split

That is generically speaking still sub-optimal, consider a sequence of tab-space-tab: is that simply visual column alignment, or does this encode an empty column? Compared to “;;” the white space solution still looks inferior to me, but again I am simple-minded… Also this is besides the point for #40 as there should be no empty columns to begin with. Final note explicit non-white space separators allow the unambiguous use of spaces in the column headers, but I digress. Best Regards

…

-Toke — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[tohojo]

moeller0 <[email protected]> writes:

That is generically speaking still sub-optimal, consider a sequence of tab-space-tab: is that simply visual column alignment, or does this encode an empty column? Compared to “;;” the white space solution still looks inferior to me, but again I am simple-minded… Also this is besides the point for #40 as there should be no empty columns to begin with. Final note explicit non-white space separators allow the unambiguous use of spaces in the column headers, but I digress.

As you yourself said: We don't have empty columns. If we were designing a new interface, you'd have a point that it would be better form a parsing perspective. But we're not, and one of the goals was to not break existing parsers :)

…

-Toke

[dtaht]

I'm all in favor of inserting a space. I don't think it will change the color of the bikeshed any. The problem right now is that the code actually truncates the result entirely, which is probably something I've puzzled over in a long term flent result (I do pound many gbytes through it).

            fprintf(f, "  bytes   ");
            for(i=0; i < stnc->tin_cnt; i++)
                    fprintf(f, "%12llu", stnc->sent[i].bytes);
            fprintf(f, "\n");

A more correct way to get things to align properly would be to go through all the columns, for all the data, find the max width, and use spaces to fix that.

My own take on all of this was that this level of abuse of tc's statistics facility would not be taken upstream, and we'll have to end up reporting all this extra stuff via sysfs.

[dtaht]

I am still unfond of the bytes bleeding.