[jitsi-dev] jitsi hammer and last N


#1

Hi,
Can somebody please explain how could I force jitsi-hammer to take into account the -channelLastN parameter. No matter what I set for this parameter - the JVB outbound traffic is approximately two times bigger than the inbound traffic. What am I missing?
Cheers,
Jernej

···

------------------------------------------------
Jernej Trnkoczy
Researcher
Faculty of Civil and Geodetic Engineering
University of Ljubljana
Phone: +386 1 4768 588
e-mail: jernej.trnkoczy@fgg.uni-lj.si<mailto:jernej.trnkoczy@fgg.uni-lj.si>
------------------------------------------------


#2

Hi Jernej,

Sorry for the lack of reply on your other thread. I'll try and reply later today.

Hi,

Can somebody please explain how could I force jitsi-hammer to take into
account the –channelLastN parameter. No matter what I set for this
parameter – the JVB outbound traffic is approximately two times bigger
than the inbound traffic. What am I missing?

I don't think jitsi-hammer support setting the channelLastN parameter when it creates a room. If you want to use it, I would advice you to enter the room with a browser, and then add hammer users afterwards (you can stop the browser after the hammers join). Hopefully this works for your use-case.

Note that if you are using simulcast the traffic pattern will be quite different than without it. The perf tests you mention in the other thread do NOT use simulcast.

Regards,
Boris

···

On 20/03/2017 12:12, Trnkoczy, Jernej wrote:


#3

The conference creation properties like channelLastN aren't working in jitsi-hammer master. Here's how I fixed it in my fork. I haven't gotten around to push it upstream yet. https://github.com/pstros/jitsi-hammer/commit/3318eae843bbdcba9fd5c2161b3ded0bbec52707

Devin

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Boris Grozev
Sent: Monday, March 20, 2017 11:47 AM
To: Jitsi Developers
Subject: Re: [jitsi-dev] jitsi hammer and last N

Hi Jernej,

Sorry for the lack of reply on your other thread. I'll try and reply later today.

On 20/03/2017 12:12, Trnkoczy, Jernej wrote:

Hi,

Can somebody please explain how could I force jitsi-hammer to take
into account the –channelLastN parameter. No matter what I set for
this parameter – the JVB outbound traffic is approximately two times
bigger than the inbound traffic. What am I missing?

I don't think jitsi-hammer support setting the channelLastN parameter when it creates a room. If you want to use it, I would advice you to enter the room with a browser, and then add hammer users afterwards (you can stop the browser after the hammers join). Hopefully this works for your use-case.

Note that if you are using simulcast the traffic pattern will be quite different than without it. The perf tests you mention in the other thread do NOT use simulcast.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business. Providing a safer and more useful place for your human generated data. Specializing in; Security, archiving and compliance. To find out more visit the Mimecast website.


#4

Hi Devin, Boris,
Thanks for reply. All I would like to have is to configure somewhere (does not matter whether on hammer or on jitsi-meet or somewhere else) that last N is disabled and simulcasting is disabled.

Currently I am using a browser to create a room and then I join this room with a hammer tool. The microphone and camera of the browser are muted.
The config.js of jitsi-meet web app. that browser loads when creating a room (https://github.com/jitsi/jitsi-meet/blob/master/config.js ) contains:
chanelLastN: -1 ,
adaptiveLastN: false,
disableSimulcast: true,

I am starting jitsi-hammer (on another computer but within the same subnet –1GBps net should be enoug) with a command like this: ./jitsi-hammer.sh -u https://MY_SERVER/http-bind -room MY_ROOM -length 120 -audiortpdump ./resources/badger-audio.rtpdump -videortpdump ./resources/badger-video.rtpdump -users 30 -channelLastN 29 –adaptiveLastN false –adaptiveSimulcast false –simulcastMode rewriting" - summarystats

Apparently - according to your response - the hammer-side parameters do not have any effect. Although I do not understand how could config.js settings influence channels created by hammer (after all this is the configuration for the browser client and not the hammer) I was hoping that with this configuration I would get 30 input streams and 30x29 output streams on the JVB. Unfortunately as I said - the output bitrate is only two times bigger than input bitrate. Also the number of icons that appear in browser (representing hammer users) is only up to maximum five (and never reaches 30 as it probably should), but on the other hand chat shows all 30 hammer users…

So I am really struggling with understanding of what settings and where (config.js or jitsi-hammer.sh arguments, or maybe both, or perhaps even some settings on JVB) should I use to:
1) disable/enable simulcast
2) control last N
3) control congestion control (The paper Last N: Relevance-Based Selectivity for Forwarding Video in Multimedia Conferences says hammer does not support congestion control )
4) Video pausing (related to last N – but I did not find any option to control this)

It should be possible without hammer code modification – because jitsi-team published a paper on this – so I imagine they did not change the source code of their own product ;).
I would really appreciate if you can give me some insights.

Cheers,
Jernej

···

From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Devin Wilson
Sent: 21. marec 2017 18:09
To: 'Jitsi Developers'
Subject: Re: [jitsi-dev] jitsi hammer and last N

The conference creation properties like channelLastN aren't working in jitsi-hammer master. Here's how I fixed it in my fork. I haven't gotten around to push it upstream yet. https://github.com/pstros/jitsi-hammer/commit/3318eae843bbdcba9fd5c2161b3ded0bbec52707

Devin

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Boris Grozev
Sent: Monday, March 20, 2017 11:47 AM
To: Jitsi Developers
Subject: Re: [jitsi-dev] jitsi hammer and last N

Hi Jernej,

Sorry for the lack of reply on your other thread. I'll try and reply later today.

On 20/03/2017 12:12, Trnkoczy, Jernej wrote:

Hi,

Can somebody please explain how could I force jitsi-hammer to take
into account the –channelLastN parameter. No matter what I set for
this parameter – the JVB outbound traffic is approximately two times
bigger than the inbound traffic. What am I missing?

I don't think jitsi-hammer support setting the channelLastN parameter when it creates a room. If you want to use it, I would advice you to enter the room with a browser, and then add hammer users afterwards (you can stop the browser after the hammers join). Hopefully this works for your use-case.

Note that if you are using simulcast the traffic pattern will be quite different than without it. The perf tests you mention in the other thread do NOT use simulcast.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org<mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

Disclaimer

The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful.

This email has been scanned for viruses and malware, and may have been automatically archived.


#5

Hi Jernej,

Hi Devin, Boris,

Thanks for reply. All I would like to have is to configure somewhere
(does not matter whether on hammer or on jitsi-meet or somewhere else)
that last N is disabled and simulcasting is disabled.

Currently I am using a browser to create a room and then I join this
room with a hammer tool. The microphone and camera of the browser are muted.

The config.js of jitsi-meet web app. that browser loads when creating a
room (https://github.com/jitsi/jitsi-meet/blob/master/config.js ) contains:

chanelLastN: -1 ,

adaptiveLastN: false,

disableSimulcast: true,

This should result in lastN being disabled for the whole conference (the first client sends channelLastN to jicofo, which sets it conference-wide and forwards it to the bridge).

Browser clients joining the conference will not use simulcast (they understand the disableSimulcast option). However, hammers which join will not be affected by this. Whether a hammer uses simulcast or not depends on the input file that you feed.

I am starting jitsi-hammer (on another computer but within the same
subnet –1GBps net should be enoug) with a command like this:
./jitsi-hammer.sh -u https://MY_SERVER/http-bind -room MY_ROOM -length
120 -audiortpdump ./resources/badger-audio.rtpdump -videortpdump
./resources/badger-video.rtpdump *-users 30* *-channelLastN 29*
*–adaptiveLastN false –adaptiveSimulcast false –simulcastMode
rewriting"* - summarystats

The badger-video.rtpdump file contains a single stream, no simulcast.

Apparently - according to your response - the hammer-side parameters do
not have any effect. Although I do not understand how could config.js
settings influence channels created by hammer (after all this is the
configuration for the browser client and not the hammer)

See above on channelLastN.

I was hoping
that with this configuration I would get 30 input streams and 30x29
output streams on the JVB. Unfortunately as I said - the output bitrate
is only two times bigger than input bitrate. Also the number of icons
that appear in browser (representing hammer users) is only up to maximum
five (and never reaches 30 as it probably should), but on the other hand
chat shows all 30 hammer users…

I would suspect that not all hammer users have connected successfully, and I suggest that you try with a smaller number of hammers (e.g. 5) and move to 30 once this works as expected.

*So I am really struggling with understanding of what settings and where
*(config.js or jitsi-hammer.sh arguments, or maybe both, or perhaps even
some settings on JVB)*should I use to:*

*1) **disable/enable simulcast*

*2) **control last N*

*3) **control congestion control *(The paper /Last N:
Relevance-Based Selectivity for Forwarding Video in Multimedia
Conferences/ says hammer does not support congestion control )

The hammer still does not support congestion control.

*4) **Video pausing *(related to last N – but I did not find any
option to control this)

This was implemented only for an experiment and not released. We have no video pausing anywhere right now.

It should be possible without hammer code modification – because
jitsi-team published a paper on this – so I imagine they did not change
the source code of their own product ;).

Yeah, well, the code was way too ugly to publish, it used custom RTCP messages :slight_smile:

Regards,
Boris

···

On 21/03/2017 12:58, Trnkoczy, Jernej wrote:


#6

Hi Boris,
Thank you very much, this explains a lot. I think it could be beneficial to add this kind of information to the README.md file of hammer - so I'll make a pull request.
One thing that I am still missing is the description of input files (provided in the ./resources folder)...

Cheers,
Jernej

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Boris Grozev
Sent: 21. marec 2017 19:26
To: Jitsi Developers
Subject: Re: [jitsi-dev] jitsi hammer and last N

Hi Jernej,

On 21/03/2017 12:58, Trnkoczy, Jernej wrote:

Hi Devin, Boris,

Thanks for reply. All I would like to have is to configure somewhere
(does not matter whether on hammer or on jitsi-meet or somewhere else)
that last N is disabled and simulcasting is disabled.

Currently I am using a browser to create a room and then I join this
room with a hammer tool. The microphone and camera of the browser are muted.

The config.js of jitsi-meet web app. that browser loads when creating
a room (https://github.com/jitsi/jitsi-meet/blob/master/config.js ) contains:

chanelLastN: -1 ,

adaptiveLastN: false,

disableSimulcast: true,

This should result in lastN being disabled for the whole conference (the first client sends channelLastN to jicofo, which sets it conference-wide and forwards it to the bridge).

Browser clients joining the conference will not use simulcast (they understand the disableSimulcast option). However, hammers which join will not be affected by this. Whether a hammer uses simulcast or not depends on the input file that you feed.

I am starting jitsi-hammer (on another computer but within the same
subnet –1GBps net should be enoug) with a command like this:
./jitsi-hammer.sh -u https://MY_SERVER/http-bind -room MY_ROOM -length
120 -audiortpdump ./resources/badger-audio.rtpdump -videortpdump
./resources/badger-video.rtpdump *-users 30* *-channelLastN 29*
*–adaptiveLastN false –adaptiveSimulcast false –simulcastMode
rewriting"* - summarystats

The badger-video.rtpdump file contains a single stream, no simulcast.

Apparently - according to your response - the hammer-side parameters
do not have any effect. Although I do not understand how could
config.js settings influence channels created by hammer (after all
this is the configuration for the browser client and not the hammer)

See above on channelLastN.

I was hoping
that with this configuration I would get 30 input streams and 30x29
output streams on the JVB. Unfortunately as I said - the output
bitrate is only two times bigger than input bitrate. Also the number
of icons that appear in browser (representing hammer users) is only up
to maximum five (and never reaches 30 as it probably should), but on
the other hand chat shows all 30 hammer users…

I would suspect that not all hammer users have connected successfully, and I suggest that you try with a smaller number of hammers (e.g. 5) and move to 30 once this works as expected.

*So I am really struggling with understanding of what settings and where
*(config.js or jitsi-hammer.sh arguments, or maybe both, or perhaps even
some settings on JVB)*should I use to:*

*1) **disable/enable simulcast*

*2) **control last N*

*3) **control congestion control *(The paper /Last N:
Relevance-Based Selectivity for Forwarding Video in Multimedia
Conferences/ says hammer does not support congestion control )

The hammer still does not support congestion control.

*4) **Video pausing *(related to last N – but I did not find any
option to control this)

This was implemented only for an experiment and not released. We have no
video pausing anywhere right now.

It should be possible without hammer code modification – because
jitsi-team published a paper on this – so I imagine they did not change
the source code of their own product ;).

Yeah, well, the code was way too ugly to publish, it used custom RTCP
messages :slight_smile:

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev