From contact at madvase.co.uk Wed Apr 4 14:59:07 2018 From: contact at madvase.co.uk (Dave Ellis) Date: Wed, 4 Apr 2018 15:59:07 +0100 Subject: Data throughput issues. Increasing throughput. In-Reply-To: <0e39f17b-557e-2e2a-6f28-0eb9d6b5afe1@sysmocom.de> References: <0e39f17b-557e-2e2a-6f28-0eb9d6b5afe1@sysmocom.de> Message-ID: Hi Pau, Thanks for the help so far. I have tried using the kernel-gtp mode and only managed to cause crashes in the omso-ggsn program. I have updated to the latest git repository for the osmo-ggsn. I followed the instructions here https://osmocom.org/projects/openggsn/wiki/Kernel_GTP to load the kernel gtp module and the 'lsmod | grep gtp' shows the same as the results in the instructions. After that the instructions mention using openggsn. I'm not sure if there is further configuration required for the kernel gtp module - do I need to create a tunnel? Or should this be done by osmo-ggsn as it did for the gtpu-mode tun setting? [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". <0002> ggsn.c:203 APN(S1U): Starting <0002> ggsn.c:281 APN(S1U): Opening Kernel GTP device gtp0 <0002> gtp-kernel.c:75 Initialized GTP kernel mode (genl ID is 30) Program received signal SIGSEGV, Segmentation fault. gtp_kernel_init (gsn=0x0, devname=0x6a6fe0 "gtp0", prefix=prefix at entry=0x6a76e0, ipup=0x0) at gtp-kernel.c:94 94 if (gtp_dev_create(-1, devname, gsn->fd0, gsn->fd1u) < 0) { I have tried, without success, to find a sample config file with the kernel-gtp mode in for osmo-ggsn. Is there a sample config file for osmo-ggsn with the kernel-gtp mode selected? This is my current config file - I have gone through various attempts with different tun_device names. ! ! OpenGGSN (0.94.1-adac) configuration saved from vty !! ! ! kernel-gtp log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level ip info logging level tun info logging level ggsn info logging level sgsn notice logging level icmp6 notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp info logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice ! stats interval 5 ! line vty no login ! ggsn tun1 gtp state-dir /tmp gtp bind-ip 172.16.8.1 apn S1U gtpu-mode kernel-gtp tun-device gtp0 type-support v4 ip prefix dynamic 10.1.1.0/24 ip dns 0 192.168.100.1 ip dns 1 8.8.8.8 ip ifconfig 10.1.1.2/24 no shutdown default-apn S1U no shutdown ggsn Thanks Dave On Thu, Mar 29, 2018 at 3:14 PM, Pau Espin Pedrol wrote: > Hi Dave, > > I never personally used it, but as far as I know you should be able to get > more performance by using "gtpu-mode kernel-gtp" instead of "gtpu-mode tun" > in your config, to avoid doing all packet processing in userspace. Please > someone else confirm this. I think you need a capable kernel and libgtpnl > to be able to use it. > > Also, it would be nice if you could provide a linux "perf" output on > osmo-ggsn while running your test setup so we can spot possible > optimizations to improve osmo-ggsn performance. > > -- > - Pau Espin Pedrol http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Director: Harald Welte > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt9j at cs.washington.edu Wed Apr 4 16:54:43 2018 From: matt9j at cs.washington.edu (Matthew Johnson) Date: Wed, 4 Apr 2018 09:54:43 -0700 Subject: Data Rate of EGPRS is Too Low In-Reply-To: <20180305221514.GA7166@my.box> References: <20180301122707.GA18710@my.box> <20180302030127.GA3507@my.box> <20180305221514.GA7166@my.box> Message-ID: Hello Xinke, I'm a graduate student at the University of Washington, and just brought up an EGPRS/GPRS network with an Ettus B210/osmo-trx. My B210 has a GPSDO as well. I'm just getting started on this project (so I'm unfortunately not the expert you are looking for), but I can corroborate that I am also seeing very limited single user throughput in EGRPS and vanilla GRPS (6-8kbps maximum measured via iperf). My network is built with the latest split components running on a debian9 virtual machine via virtualbox. I'll attach my configs here if they're helpful. I also have access to a litecell1.5 and will be bringing up the network on it in the next few weeks, so I'll be able to report if it behaves any better. The litecell setup will also be running on dedicated hardware to rule out any strangeness from virtualbox. Sorry I don't have any other clues at this time, but I can at least confirm Neels's analysis above and rule out the impact of running the old nitb and ggsn. Cheers, -Matt Johnson On Mon, Mar 5, 2018 at 2:15 PM, Neels Hofmeyr wrote: > On Sat, Mar 03, 2018 at 12:18:52PM +0000, XINKE ZHANG wrote: > > I'm sure that B210 has a GPSDO. I execute 'uhd_usrp_probe' to prove it. > > I'm not familiar with it, but if you say so. > > > My entire config files are attached here. Pls help check it. Thanks. > > It all looks good to me. Two minor notes: > > - the pcu config once needed 'two-phase-access' to function reliably, but > this > is no longer needed. > > - you seem to be running an old version of the ggsn. The new one is called > osmo-ggsn with a config file style and vty interface like the other osmo > programs. However, this should not affect your downlink throughput. > > - you also seem to run osmo-nitb, we have moved to separate programs, being > osmo-hlr, osmo-msc and osmo-bsc. Refer to > http://osmocom.org/projects/cellular-infrastructure/wiki/ > Osmocom_Network_In_The_Box > This should, however, not affect your downlink throughput, either. > > So yeah, sorry, but I have nothing of weight to add. Maybe someone else > here > has deeper knowledge of EGPRS and SDR based BTS? > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nitb.tar.gz Type: application/gzip Size: 3024 bytes Desc: not available URL: From pespin at sysmocom.de Thu Apr 5 09:58:12 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 5 Apr 2018 11:58:12 +0200 Subject: Data throughput issues. Increasing throughput. In-Reply-To: References: <0e39f17b-557e-2e2a-6f28-0eb9d6b5afe1@sysmocom.de> Message-ID: Hi, On 04/04/18 16:59, Dave Ellis wrote: > After that the instructions mention using openggsn.? I'm not sure if > there is further configuration required for the kernel gtp module - do I > need to create a tunnel? Or should this be done by osmo-ggsn as it did > for the gtpu-mode tun setting? I'm not sure here since I didn't find the opportunity to use the gtp kernel module myself yet. Looking at code in osmo-ggsn gtp-kernel.c, gtp_kernel_init() calls gtp_dev_create() which seems to create a GTP tunnel device, so osmo-ggsn seems to be creating the device. > > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > <0002> ggsn.c:203 APN(S1U): Starting > <0002> ggsn.c:281 APN(S1U): Opening Kernel GTP device gtp0 > <0002> gtp-kernel.c:75 Initialized GTP kernel mode (genl ID is 30) > > Program received signal SIGSEGV, Segmentation fault. > gtp_kernel_init (gsn=0x0, devname=0x6a6fe0 "gtp0", > ? ? prefix=prefix at entry=0x6a76e0, ipup=0x0) at gtp-kernel.c:94 > 94if (gtp_dev_create(-1, devname, gsn->fd0, gsn->fd1u) < 0) { > This looks like a bug in the code (gsn=NULL). Please open a ticket in redmine in OsmoGGSN project to remember to have a look at it. Also compiling everything with CFLAGS="-g -O0", then running under gdb and providing a full backtrace may help pinpoint the issue quicker. Feel free to open a new task also about the bad performance when running without gtp kernel support and providing some performance figures, and if possible a linux perf output of the process. -- - Pau Espin Pedrol http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From laforge at gnumonks.org Wed Apr 11 20:22:08 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 11 Apr 2018 22:22:08 +0200 Subject: Save the Date: OsmoCon 2018 on October 18-19, 2018 Message-ID: <20180411202208.GD28162@nataraja> == OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From xinke.zhang at hotmail.com Thu Apr 12 07:43:03 2018 From: xinke.zhang at hotmail.com (XINKE ZHANG) Date: Thu, 12 Apr 2018 07:43:03 +0000 Subject: Data Rate of EGPRS is Too Low In-Reply-To: References: <20180301122707.GA18710@my.box> <20180302030127.GA3507@my.box> <20180305221514.GA7166@my.box>, Message-ID: Hi Matthew, I'm sorry for late reply. I have also tested the latest split components running on a xubuntu 14.04 machine, but the throughput is very limited. I buy a test phone, and find that the dl bler is so high. In my opinion, the high dl bler causes the low throughput. Nowadays, I'm trying to locate issues, but there is no progress. Best Regards, Xinke ________________________________ From: Matthew Johnson Sent: Wednesday, April 4, 2018 16:54 To: Neels Hofmeyr Cc: XINKE ZHANG; osmocom-net-gprs at lists.osmocom.org Subject: Re: Data Rate of EGPRS is Too Low Hello Xinke, I'm a graduate student at the University of Washington, and just brought up an EGPRS/GPRS network with an Ettus B210/osmo-trx. My B210 has a GPSDO as well. I'm just getting started on this project (so I'm unfortunately not the expert you are looking for), but I can corroborate that I am also seeing very limited single user throughput in EGRPS and vanilla GRPS (6-8kbps maximum measured via iperf). My network is built with the latest split components running on a debian9 virtual machine via virtualbox. I'll attach my configs here if they're helpful. I also have access to a litecell1.5 and will be bringing up the network on it in the next few weeks, so I'll be able to report if it behaves any better. The litecell setup will also be running on dedicated hardware to rule out any strangeness from virtualbox. Sorry I don't have any other clues at this time, but I can at least confirm Neels's analysis above and rule out the impact of running the old nitb and ggsn. Cheers, -Matt Johnson On Mon, Mar 5, 2018 at 2:15 PM, Neels Hofmeyr > wrote: On Sat, Mar 03, 2018 at 12:18:52PM +0000, XINKE ZHANG wrote: > I'm sure that B210 has a GPSDO. I execute 'uhd_usrp_probe' to prove it. I'm not familiar with it, but if you say so. > My entire config files are attached here. Pls help check it. Thanks. It all looks good to me. Two minor notes: - the pcu config once needed 'two-phase-access' to function reliably, but this is no longer needed. - you seem to be running an old version of the ggsn. The new one is called osmo-ggsn with a config file style and vty interface like the other osmo programs. However, this should not affect your downlink throughput. - you also seem to run osmo-nitb, we have moved to separate programs, being osmo-hlr, osmo-msc and osmo-bsc. Refer to http://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box This should, however, not affect your downlink throughput, either. So yeah, sorry, but I have nothing of weight to add. Maybe someone else here has deeper knowledge of EGPRS and SDR based BTS? ~N -------------- next part -------------- An HTML attachment was scrubbed... URL: From ssprasad at vanu.com Tue Apr 17 00:59:48 2018 From: ssprasad at vanu.com (Shashank Prasad) Date: Tue, 17 Apr 2018 00:59:48 +0000 Subject: GTP-U support for a UE with multiple bearers (LTE) Message-ID: Hi, I just started exploring the GTP-U module (maintained in the kernel) for LTE. In LTE, a UE can be associated with multiple bearers. This implies that an MS IP address can be associated with multiple TEIDs (one for each bearer). Based on browsing the kernel GTP implementation[1], it looks like the GTP-U (maintained in the kernel) can only support 1 TEID per MS IP address. In which case, the GTP implementation, as is, may NOT be usable by LTE modules. Is this a correct interpretation? - Shashank [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/drivers/net/gtp.c?h=v4.17-rc1 From ssprasad at vanu.com Tue Apr 17 00:35:36 2018 From: ssprasad at vanu.com (Shashank Prasad) Date: Tue, 17 Apr 2018 00:35:36 +0000 Subject: GTP-U support for a UE with multiple bearers Message-ID: Hi, I just started exploring the GTP-U module (maintained in the kernel) for LTE scenarios. In LTE, a UE can be associated with multiple bearers. This implies that an MS IP address can be associated with multiple TEIDs (one for each bearer). Based on browsing the kernel GTP implementation[1], it looks like the GTP-U (maintained in the kernel) can only support 1 TEID per MS IP address. In which case, the GTP implementation, as is, may NOT be usable by LTE modules. Is it an correct interpretation? - Shashank [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/drivers/net/gtp.c?h=v4.17-rc1 From laforge at gnumonks.org Wed Apr 18 10:41:21 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 18 Apr 2018 12:41:21 +0200 Subject: GTP-U support for a UE with multiple bearers (LTE) In-Reply-To: References: Message-ID: <20180418104121.GG17214@nataraja> Hi Shashank, your reading of the code is correct. The module was developed for 2G/3G use cases at the time. It does very well support scenarios with multiple PDP contexts that each have their own IP addresses, but it would not work for scenarios where you'd need to have multiple EPS bearers (PFCs?) that all share one MS/UE-side IP address. Having said this, nothing prevents you or any third party to contribute related patches to the kernel to extend the existing feature set. What I'm slightly worried about is the filtering criteria based on which you decide whihc TEID/tunnel/EPS-bearer you're using. After all, one doesn't want to invent yet another packet filter in the kernel and if possible reuse any of the existing infrastructure. Can you point me to the relevant 3GPP spec that lists the filter / matching criteria that would need to be supported for traffic from the Gi side to decide which TEID to use? Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)