ETTV Public beta 7
Moderators: Forum moderators, developers
ETTV Public beta 7
ETTV is now available for public beta testing.
Download it here.
Documentation is here.
New:
New console command ff to fast forward demos. Eg ff 30 will fast foward 30 seconds. Fast forward stops at map restarts, so you can safely ff 999 to fast forward through a warmup.
Chat passwords:
In order to curb the rampant abuse of ettv chat, admins may set "chat passwords" on their servers. If enabled, viewers are not allowed to chat unless they have a password. You can define as many passwords as you like, so you can easily track down individual abusers and limit the damage of stolen passwords.
ettv_chatpasswords (default 0, disabled). number of chat passwords defined.
ettv_chatpassword(1-99999). individual chat passwords.
viewers use /chatpassword (password) to login.
if logged in, ettv chats will be tagged with a number in parentheses identifying which chat password the viewer is using.
Network tuning:
By default, et uses small packets of 1400 bytes or less to send to clients. If messages need to be larger, they are 'fragmented' and sent over several server frames. ettv slave messages tend to be large and often fragment. ettv normally tries to send slaves all fragments at once to avoid jittery playback, but some networks / OSes handle this badly. ettv beta 7 introduces new controls so admins can optimize ettv for their individual network.
ettv_netblast (default 1). by default, ettv tries to send all fragments at once. some networks may handle this badly. setting this to 0 disables. warning: setting this to 0 without increasing ettv_mtu will result in severely laggy slave playback.
ettv_mtu (default 1400). if your network / os supports it, you can set this to large values (eg 16000) to prevent message fragmentation and provide smoother ettv links. this cvar has no effect on normal ET clients. note: ettv_mtu must currently be set from commandline, it cannot be changed on the fly (yet).
ettv_tv_iptos (default 0). you can set the ip type of service field of ettv link packets. if your network/ISP supports it, you can use a value like 16 ("minimize delay") to prioritize ettv link packets over others on the network.
ettv_sv_iptos (default 0). same as ettv_tv_iptos, but affects packets for normal ET clients.
Bugfixes:
com_watchdog failed in some cases. fixed.
SVF_SELF_PORTAL was broken in dedicated server engine. fixed in ettv.
Download it here.
Documentation is here.
New:
New console command ff to fast forward demos. Eg ff 30 will fast foward 30 seconds. Fast forward stops at map restarts, so you can safely ff 999 to fast forward through a warmup.
Chat passwords:
In order to curb the rampant abuse of ettv chat, admins may set "chat passwords" on their servers. If enabled, viewers are not allowed to chat unless they have a password. You can define as many passwords as you like, so you can easily track down individual abusers and limit the damage of stolen passwords.
ettv_chatpasswords (default 0, disabled). number of chat passwords defined.
ettv_chatpassword(1-99999). individual chat passwords.
viewers use /chatpassword (password) to login.
if logged in, ettv chats will be tagged with a number in parentheses identifying which chat password the viewer is using.
Network tuning:
By default, et uses small packets of 1400 bytes or less to send to clients. If messages need to be larger, they are 'fragmented' and sent over several server frames. ettv slave messages tend to be large and often fragment. ettv normally tries to send slaves all fragments at once to avoid jittery playback, but some networks / OSes handle this badly. ettv beta 7 introduces new controls so admins can optimize ettv for their individual network.
ettv_netblast (default 1). by default, ettv tries to send all fragments at once. some networks may handle this badly. setting this to 0 disables. warning: setting this to 0 without increasing ettv_mtu will result in severely laggy slave playback.
ettv_mtu (default 1400). if your network / os supports it, you can set this to large values (eg 16000) to prevent message fragmentation and provide smoother ettv links. this cvar has no effect on normal ET clients. note: ettv_mtu must currently be set from commandline, it cannot be changed on the fly (yet).
ettv_tv_iptos (default 0). you can set the ip type of service field of ettv link packets. if your network/ISP supports it, you can use a value like 16 ("minimize delay") to prioritize ettv link packets over others on the network.
ettv_sv_iptos (default 0). same as ettv_tv_iptos, but affects packets for normal ET clients.
Bugfixes:
com_watchdog failed in some cases. fixed.
SVF_SELF_PORTAL was broken in dedicated server engine. fixed in ettv.
Last edited by bani on Sun Oct 30, 2005 9:01 pm, edited 2 times in total.
good work ![Smile :-)](./images/smilies/icon_smile.gif)
Can you say if this bug: http://bani.anime.net/banimod/forums/vi ... php?t=6070
was fixed and what settings are required to fix it
![Smile :-)](./images/smilies/icon_smile.gif)
Can you say if this bug: http://bani.anime.net/banimod/forums/vi ... php?t=6070
was fixed and what settings are required to fix it
the settings to fix lag will be dependent on your individual network and how your ISP has their routers configured.
ettv_mtu 16000 should be ok for most networks.
you can also try ettv_tv_iptos 16, this may or may not have any effect depending on what kind of QOS your ISP supports on their routers.
the easiest way to test is to connect a non delayed (live) slave to a master, and change settings until you get the least amount of lag.
ettv_mtu 16000 should be ok for most networks.
you can also try ettv_tv_iptos 16, this may or may not have any effect depending on what kind of QOS your ISP supports on their routers.
the easiest way to test is to connect a non delayed (live) slave to a master, and change settings until you get the least amount of lag.
- EagleReloaded
- Posts: 278
- Joined: Fri Nov 19, 2004 9:15 pm
- Location: Sydney, Australia
nice that you made these settings, but i am not sure if this will fix the problem. There must be something that was changed from ettv b4 to ettv b6 that causes these lags - a lot of people have seen it happen, and it doesnt happen with ettv b4.bani wrote:the settings to fix lag will be dependent on your individual network and how your ISP has their routers configured.
I really dont think, that a too large mtu causes exactly every 50th frame to be skipped - that must have other reasons ...
we will test ettv b7 for these lags though and hope that they dont apear in this version
ettv_mtu is changed on the master. there are two kinds of mtu - link layer mtu (ethernet: typically 1500) and datagram mtu (see rfc791). ettv_mtu changes the datagram mtu.
ok, sounds logical
1400 is good for normal players, because et has a inbuilt maxrate of 25000byte/s - having that a server runs with 20 frames, one frame or packet will have a maximum datagram size of 1250bytes
increasing this value for ettv and thus decreasing the number of packets per second may help - will check it in the comming days ...
1400 is good for normal players, because et has a inbuilt maxrate of 25000byte/s - having that a server runs with 20 frames, one frame or packet will have a maximum datagram size of 1250bytes
increasing this value for ettv and thus decreasing the number of packets per second may help - will check it in the comming days ...
This looks great
. I will try to test this new release soon!
Just a theoretical question on ettv_sv_iptos for the client side:
- does this have any impact on gameplay on the master server? I mean suppose we run our gameservers with ettv.x86 binary and set in our configs ettv_sv_iptos 16, would we notice any difference? Or is this setting only meant for spectators connecting to a slave?
![Cool 8)](./images/smilies/icon_cool.gif)
Just a theoretical question on ettv_sv_iptos for the client side:
- does this have any impact on gameplay on the master server? I mean suppose we run our gameservers with ettv.x86 binary and set in our configs ettv_sv_iptos 16, would we notice any difference? Or is this setting only meant for spectators connecting to a slave?
Our servers now run on 64 bit steroids. Point your ET to:
- Forgotten Ground StopWatch Server with occasional wolfrof 1
- Fraggle Rock ETPub Server - Mix up ET/UT & Duke Nukem
- Forgotten Ground StopWatch Server with occasional wolfrof 1
- Fraggle Rock ETPub Server - Mix up ET/UT & Duke Nukem
it's both for regular gameplay or ettv spectators. whether it has any real effect will depend on your individual ISP and network.deej wrote:This looks great. I will try to test this new release soon!
Just a theoretical question on ettv_sv_iptos for the client side:
- does this have any impact on gameplay on the master server? I mean suppose we run our gameservers with ettv.x86 binary and set in our configs ettv_sv_iptos 16, would we notice any difference? Or is this setting only meant for spectators connecting to a slave?
But it can't hurt?
Our servers now run on 64 bit steroids. Point your ET to:
- Forgotten Ground StopWatch Server with occasional wolfrof 1
- Fraggle Rock ETPub Server - Mix up ET/UT & Duke Nukem
- Forgotten Ground StopWatch Server with occasional wolfrof 1
- Fraggle Rock ETPub Server - Mix up ET/UT & Duke Nukem
on most ipv4 networks, iptos is nether taken care of, nor routed.
so its very likely that your provider wont care about it, but aditionally remove the info from the packet and set it to default when routing.
provider's links are usually way overdimensioned so i dont think that even if the routers would care it wouldnt make any difference - as long as there is enough capacity, everything is rooted minimum delay ...
so its very likely that your provider wont care about it, but aditionally remove the info from the packet and set it to default when routing.
provider's links are usually way overdimensioned so i dont think that even if the routers would care it wouldnt make any difference - as long as there is enough capacity, everything is rooted minimum delay ...