This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-net-gprs@lists.osmocom.org/.
Andreas Eversberg andreas at eversberg.euHolger Hans Peter Freyther wrote: > Hi, > > I have added rate counters to the PCU and noticed that a lot of frames > in the DL are re-sent without there actually being any NACK or > transmission errors. dear holger, i can only guess what causes the issues you describe. so i suggest that we should do a debug session at the congress, if you attend to it and find the time. generally there is always a re-send due to delay between pcu and the radio interface. if all rlc/mac data blocks of an llc frame have been sent to the phone, a packet downlink ack control block is requested and scheduled. the pcu repeats all unacknowledged data blocks in a loop until it receives that requested control block. this way the pcu starts re-sending data blocks that might got lost, before it actually knows if and which blocks still need to be resend. (this procedure is described in TS 04.60.) > I have also re-produced a "stall" by just using > ping with a big enough data size and a low enough interval (the PCU > appears to transmit the ICMP PING but the MS never gets to send a PONG > packet). > could this be an mtu issue at the phone? does the phone requests an uplink tbf to send a pong? > In both cases it could be a scheduling issue (e.g. we don't schedule > the UL Packet ACK/NACK). in case of an ongoing uplink tbf, we ack/nack received or timed out uplink rlc/mac blocks by using a control block. even if there is an ongoing downlink tbf, all control blocks have priority over data blocks. > Is any of you aware of it? I had already > highlighted that the scheduling is not fair. I wonder if we are seeing > starvation (and will re-factor to be able to unit test this). > > In terms of scheduling. For the SBA we are already having a reservation > that we try to honor in multiple places. Maybe it is time to extend it > and have more reservations? > uplink control messages are reserved in the tbf object (poll_fn). the sba control messages are reserved in a separate structure, since sba are not (or not yet) related to a tbf. regards, andreas