This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
playground:mission-log-template1 [2015-06-18 09:07] – [Power Consumption Analysis] chrono | playground:mission-log-template1 [2015-07-15 13:59] (current) – chrono | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== | + | ====== |
- | In a past Mission-Log, we've reviewed | + | In order to mitigate the problem of having no internet at all, we got a SIM-Card for LTE/4Ǵ. At the same time the Telekom Speedstick V LTE (which is basically a rebranded Huawei 3372s) became available and not too expensive. A little research showed |
- | ====== ====== | + | < |
+ | $ echo " | ||
+ | $ udhcpc wwan0 | ||
+ | </ | ||
- | ===== Power Consumption Analysis ===== | + | and should be done with it. In reality this became quite a quest but with combined efforts we managed to get it to work and created a patch for current kernels (tested 3.18.[11-18]. If you also have this stick and are unable to get an IP via dhcp, this patch might be for you. |
- | For better comparison all measurement results have been put together: | + | < |
+ | $ make clean | ||
+ | $ make target/ | ||
+ | $ cd build_dir/ | ||
+ | $ patch -p1 -i / | ||
+ | </ | ||
- | | || DGS-1008D G2 || DGS-1008D G3 || DGS-1100-8 Rev A1 || | + | <sxh c> |
- | | || {{: | + | diff -u a/ |
- | | Clients |Mode|Current|Power|Current|Power|Current |Power| Wall | | + | --- a/ |
- | | 0 | Switch only | 66-93mA | 0.33-0.46W | 67-111mA | 0.33-0.55W | 105mA | | 0.8W | | + | +++ b/ |
- | | 1 | Client Stdby | 100-160mA | 0.5-0.8W | 109-124mA | 0.54-0.62W | 131mA | | 1W | | + | @@ -158,7 +158,7 @@ |
- | | 2 | Client Stdby | 141-194mA | 0.70-0.97W | 153-161mA | 0.76-0.80W | 154mA | | 1.1W | | + | if (!cdc_ncm_comm_intf_is_mbim(intf-> |
- | | 2 | Client Idle | 160-200mA | 0.8-1W | 170mA | 0.85W | 212mA | | 1.5W | | + | goto err; |
- | | 3 | Client SCP | 250mA | 1.25W | 210-220mA | 1.07W | 238mA | | 1.7W | | + | |
- | | 4 | Client SCP | 250mA | 1.25W | 210-220mA | 1.07W | 264mA | | 1.9W | | + | |
+ | - ret = cdc_ncm_bind_common(dev, | ||
+ | + ret = cdc_ncm_bind_common(dev, | ||
+ | if (ret) | ||
+ | | ||
- | ===== Reliability & Performance ===== | + | diff -u a/ |
+ | --- a/ | ||
+ | +++ b/ | ||
+ | @@ -684,10 +684,11 @@ | ||
+ | | ||
+ | } | ||
- | The DGS-1008D test candidate has been up and running 24x7 for more than 365 days now without any glitch or the necessity to power cycle. Power saving often leads to compromises in performance but the switch performed equally well compared to a CISCO 3560, that was in use before power consumption became a major issue. | + | + kfree(ctx-> |
+ | | ||
+ | } | ||
- | ===== Conclusion ===== | + | -int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_altsetting) |
+ | +int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_altsetting, | ||
+ | { | ||
+ | | ||
+ | | ||
+ | @@ -855,6 +856,17 @@ | ||
+ | /* finish setting up the device specific data */ | ||
+ | | ||
- | Grid powered devices still have the luxury | + | + /* Device-specific flags */ |
+ | + ctx-> | ||
+ | + | ||
+ | + /* Allocate | ||
+ | + if (ctx-> | ||
+ | + ctx-> | ||
+ | + if (!ctx-> | ||
+ | + goto error2; | ||
+ | + dev_info(& | ||
+ | + } | ||
+ | + | ||
+ | /* override ethtool_ops */ | ||
+ | | ||
+ | @@ -954,8 +966,11 @@ | ||
+ | if (cdc_ncm_select_altsetting(intf) != CDC_NCM_COMM_ALTSETTING_NCM) | ||
+ | | ||
+ | |||
+ | - /* The NCM data altsetting is fixed */ | ||
+ | - ret = cdc_ncm_bind_common(dev, | ||
+ | + /* The NCM data altsetting is fixed, so we hard-coded it. | ||
+ | + * Additionally, | ||
+ | + * placed NDP. | ||
+ | + */ | ||
+ | + ret = cdc_ncm_bind_common(dev, | ||
+ | |||
+ | /* | ||
+ | * We should get an event when network connection is " | ||
+ | @@ -986,6 +1001,14 @@ | ||
+ | | ||
+ | | ||
+ | |||
+ | + /* If NDP should | ||
+ | + * NTH16 header as we would normally do. NDP isn't written to the SKB yet, and | ||
+ | + * the wNdpIndex field in the header is actually | ||
+ | + */ | ||
+ | + if (ctx-> | ||
+ | + if (ctx-> | ||
+ | + return ctx-> | ||
+ | + | ||
+ | /* follow the chain of NDPs, looking for a match */ | ||
+ | | ||
+ | | ||
+ | @@ -995,7 +1018,8 @@ | ||
+ | } | ||
+ | |||
+ | /* align new NDP */ | ||
+ | - cdc_ncm_align_tail(skb, | ||
+ | + if (!(ctx-> | ||
+ | + cdc_ncm_align_tail(skb, | ||
+ | |||
+ | /* verify | ||
+ | if ((ctx-> | ||
+ | @@ -1008,7 +1032,11 @@ | ||
+ | | ||
+ | |||
+ | /* push a new empty NDP */ | ||
+ | - ndp16 = (struct usb_cdc_ncm_ndp16 *)memset(skb_put(skb, | ||
+ | + if (!(ctx-> | ||
+ | + ndp16 = (struct usb_cdc_ncm_ndp16 *)memset(skb_put(skb, | ||
+ | + else | ||
+ | + ndp16 = ctx-> | ||
+ | + | ||
+ | | ||
+ | | ||
+ | | ||
+ | @@ -1023,6 +1051,15 @@ | ||
+ | | ||
+ | u16 n = 0, index, ndplen; | ||
+ | u8 ready2send = 0; | ||
+ | + u32 delayed_ndp_size; | ||
+ | + | ||
+ | + /* When our NDP gets written in cdc_ncm_ndp(), | ||
+ | + * accordingly. Otherwise, we should check here. | ||
+ | + */ | ||
+ | + if (ctx-> | ||
+ | + delayed_ndp_size = ctx-> | ||
+ | + else | ||
+ | + delayed_ndp_size = 0; | ||
+ | |||
+ | /* if there is a remaining skb, it gets priority */ | ||
+ | if (skb != NULL) { | ||
+ | @@ -1077,7 +1114,7 @@ | ||
+ | | ||
+ | |||
+ | /* check if we had enough room left for both NDP and frame */ | ||
+ | - if (!ndp16 || skb_out-> | ||
+ | + if (!ndp16 || skb_out-> | ||
+ | if (n == 0) { | ||
+ | | ||
+ | | ||
+ | |||
+ | @@ -1150,6 +1187,17 @@ | ||
+ | /* variables will be reset at next call */ | ||
+ | } | ||
+ | |||
+ | + /* If requested, put NDP at end of frame. */ | ||
+ | + if (ctx-> | ||
+ | + nth16 = (struct usb_cdc_ncm_nth16 *)skb_out-> | ||
+ | + cdc_ncm_align_tail(skb_out, ctx-> | ||
+ | + nth16-> | ||
+ | + memcpy(skb_put(skb_out, | ||
+ | + | ||
+ | + /* Zero out delayed NDP - signature checking will naturally fail. */ | ||
+ | + ndp16 = memset(ctx-> | ||
+ | + } | ||
+ | + | ||
+ | /* If collected data size is less or equal ctx-> | ||
+ | * bytes, we send buffers | ||
+ | * would be more efficient for USB HS mobile device with DMA | ||
+ | diff -u a/ | ||
+ | --- a/ | ||
+ | +++ b/ | ||
+ | @@ -73,11 +73,14 @@ | ||
+ | | ||
+ | int ret = -ENODEV; | ||
+ | | ||
+ | + int drvflags = 0; | ||
+ | |||
+ | /* altsetting should always be 1 for NCM devices - so we hard-coded | ||
+ | - * it here | ||
+ | + * it here. Some huawei devices will need the NDP part of the NCM package to | ||
+ | + * be at the end of the frame. | ||
+ | */ | ||
+ | - ret = cdc_ncm_bind_common(usbnet_dev, | ||
+ | + drvflags |= CDC_NCM_FLAG_NDP_TO_END; | ||
+ | + ret = cdc_ncm_bind_common(usbnet_dev, | ||
+ | if (ret) | ||
+ | | ||
+ | |||
+ | diff -u a/ | ||
+ | --- a/ | ||
+ | +++ b/ | ||
+ | @@ -80,6 +80,9 @@ | ||
+ | # | ||
+ | # | ||
+ | |||
+ | +/* Driver flags */ | ||
+ | +#define CDC_NCM_FLAG_NDP_TO_END 0x02 / | ||
+ | + | ||
+ | # | ||
+ | | ||
+ | # | ||
+ | @@ -103,9 +106,11 @@ | ||
+ | |||
+ | | ||
+ | | ||
+ | + int drvflags; | ||
+ | |||
+ | u32 timer_interval; | ||
+ | u32 max_ndp_size; | ||
+ | + struct usb_cdc_ncm_ndp16 *delayed_ndp16; | ||
+ | |||
+ | u32 tx_timer_pending; | ||
+ | u32 tx_curr_frame_num; | ||
+ | @@ -133,7 +138,7 @@ | ||
+ | }; | ||
+ | |||
+ | u8 cdc_ncm_select_altsetting(struct usb_interface *intf); | ||
+ | -int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_altsetting); | ||
+ | +int cdc_ncm_bind_common(struct usbnet *dev, struct usb_interface *intf, u8 data_altsetting, | ||
+ | void cdc_ncm_unbind(struct usbnet *dev, struct usb_interface *intf); | ||
+ | | ||
+ | int cdc_ncm_rx_verify_nth16(struct cdc_ncm_ctx *ctx, struct sk_buff *skb_in); | ||
+ | </ | ||
- | There are still a lot of devices out there with a standby-consumption of well above 10W, the DGS-1008D G3 connects 4 clients, actively transfers a lot of data and consumes about 1W. D-link obviously did a good job with this, although there is a little curiosity in StandBy: The G2 consumes a little less power in StandBy, when no clients are connected but the G3 saves considerably more power when active so overall the G3 is a very good evolutionary step in low-power consumption Gigabit-Ethernet technology. | ||
- | The only drawback of these switches is their un-managed nature. Hopefully, in the future even managed switches can operate with this kind of power consumption profile. | ||
- | Other manufacturers, | ||
{{tag> | {{tag> | ||
~~DISCUSSION~~ | ~~DISCUSSION~~ |