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

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.

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.

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.

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,

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.

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.

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.

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.

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:*

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)...

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.

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:*