search for: clamped

Hello, I have an interesting question. I can''t find a solution anywhere to this problem. I have an adsl connection which is able to send a full data packet in about 150ms. I want to cut this time down to decrease latency while serving files, so I thought I''d try and reduce the packet size for the offending upload streams (my webserver). The trick is that I also want all other

Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > The Tegra124 and later Tegra SoCs have a sepatate rail gating register > to enable/disable the clamp. The original function > tegra_powergate_remove_clamping() is not sufficient for the enable > function. So add a new function which is dedicated to the GPU rail > gating. Also don't refer to the powergate ID since the

Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 109 +++++++++++++++++++++ 1 file changed, 109 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp

...I did wrong to prevent it from working as intended :-). I''d rather not leave the MTU set to 1000 for all packets leaving my XP machine, because that''ll reduce my throughput. I''d really rather have things work as intended, i.e., have only traffic going through the VPN be clamped. Any suggestions for what I might be doing wrong and/or how to debug the problem further? Thank you, Jonathan Kamens _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ------- End of...

The Tegra124 and later Tegra SoCs have a sepatate rail gating register to enable/disable the clamp. The original function tegra_powergate_remove_clamping() is not sufficient for the enable function. So add a new function which is dedicated to the GPU rail gating. Also don't refer to the powergate ID since the GPU ID makes no sense here. Signed-off-by: Vince Hsu <vinceh at nvidia.com>

Am Donnerstag, den 25.12.2014, 10:28 +0800 schrieb Vince Hsu: > On 12/24/2014 09:16 PM, Lucas Stach wrote: > > Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >> The Tegra124 and later Tegra SoCs have a sepatate rail gating register > >> to enable/disable the clamp. The original function > >> tegra_powergate_remove_clamping() is not sufficient for

Folding for conversions: F32/64->(U16/32, S16/32) and (U16/32, S16/32)->F32 No piglit regressions observed on nv50 and nvc0! Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- V2: fix usage of wrong variable V3: enable F64 support V4: - disable F64 support again - handle saturate flag: clamp to min/max if needed

On 12/24/2014 09:16 PM, Lucas Stach wrote: > Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >> The Tegra124 and later Tegra SoCs have a sepatate rail gating register >> to enable/disable the clamp. The original function >> tegra_powergate_remove_clamping() is not sufficient for the enable >> function. So add a new function which is dedicated to the GPU rail

On 12/26/2014 04:34 AM, Lucas Stach wrote: > Am Donnerstag, den 25.12.2014, 10:28 +0800 schrieb Vince Hsu: >> On 12/24/2014 09:16 PM, Lucas Stach wrote: >>> Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >>>> The Tegra124 and later Tegra SoCs have a sepatate rail gating register >>>> to enable/disable the clamp. The original function

On Tue, Jan 06, 2015 at 10:11:41AM +0800, Vince Hsu wrote: > > On 01/05/2015 11:09 PM, Thierry Reding wrote: > >* PGP Signed by an unknown key > > > >On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > >>On 12/24/2014 09:16 PM, Lucas Stach wrote: > >>>Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >>>>The Tegra124

Hey, My internet is provided via ADSL using PPPoE. When I take a look at ifconfig''s output, I see that eth0 has an MTU of 1500, and ppp0 has an MTU of 1492. I don''t _think_ that rp-pppoe (my pppoe util) is clamping the MSS. I am noticing some latency when there''s a lot of bandwidth in use (but not >90%). What should I clamp, eth0/ppp0? How much? And what with,

...mpting to throttle egress traffic to a specific rate using a tbf. As a starting point I used an example from the LARTC howto, which goes: tc qdisc add dev eth1 root tbf rate 220kbit latency 50ms burst 1540 I then attempt a large fetch from another machine via wget (~40 megs) and the rate was clamped down to about 12Kbytes/s. As this seemed too much, I gradually increased the latency up to 200ms which then gave me the expected results (~34Kbytes/s). I then applied this queuing discipline on a machine acting as a gateway/router for a few VLANed subnets. The tbf was applied on interface et...

On 01/05/2015 11:09 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: >> On 12/24/2014 09:16 PM, Lucas Stach wrote: >>> Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: >>>> The Tegra124 and later Tegra SoCs have a sepatate rail gating register >>>> to enable/disable

On 01/06/2015 07:15 PM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Tue, Jan 06, 2015 at 10:11:41AM +0800, Vince Hsu wrote: >> On 01/05/2015 11:09 PM, Thierry Reding wrote: >>>> Old Signed by an unknown key >>> On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: >>>> On 12/24/2014 09:16 PM, Lucas Stach wrote:

Folding for conversions: F32/64->(U16/32, S16/32) and (U16/32, S16/32)->F32 No piglit regressions observed on nv50 and nvc0! Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> --- V2: fix usage of wrong variable V3: enable F64 support V4: - disable F64 support again - handle saturate flag: clamp to min/max if needed V5: clamp before rounding to nearest

On Thu, Dec 25, 2014 at 10:28:08AM +0800, Vince Hsu wrote: > On 12/24/2014 09:16 PM, Lucas Stach wrote: > >Am Dienstag, den 23.12.2014, 18:39 +0800 schrieb Vince Hsu: > >>The Tegra124 and later Tegra SoCs have a sepatate rail gating register > >>to enable/disable the clamp. The original function > >>tegra_powergate_remove_clamping() is not sufficient for the

On Tue, Jan 06, 2015 at 08:03:03PM +0800, Vince Hsu wrote: > On 01/06/2015 07:15 PM, Thierry Reding wrote: > >* PGP Signed by an unknown key > > > >On Tue, Jan 06, 2015 at 10:11:41AM +0800, Vince Hsu wrote: > >>On 01/05/2015 11:09 PM, Thierry Reding wrote: > >>>>Old Signed by an unknown key > >>>On Thu, Dec 25, 2014 at 10:28:08AM +0800,

On 3/20/19 5:11 PM, Richard W.M. Jones wrote: > These plugins are both based on the same sparse array structure which > supports a simple implementation of extents. > --- > +int > +sparse_array_extents (struct sparse_array *sa, > + uint32_t count, uint64_t offset, > + struct nbdkit_extents *extents) > +{ > + uint32_t n, type;

On 02:29:32PM Jan 06, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Tue, Jan 06, 2015 at 08:03:03PM +0800, Vince Hsu wrote: > > On 01/06/2015 07:15 PM, Thierry Reding wrote: > > >> Old Signed by an unknown key > > > > > >On Tue, Jan 06, 2015 at 10:11:41AM +0800, Vince Hsu wrote: > > >>On 01/05/2015 11:09 PM, Thierry Reding

Every hour I get a mail from logcheck with a line like Nov 6 12:08:34 wheat fetchnews[13617]: clamping maxage for comp.os.linux.admin to global expire 50 The strange thing is that syslog is filled with similar lines, but this is the only one I get in the report. It is the last such line in each group: # many similar lines deleted Nov 6 12:08:32 wheat fetchnews[13617]: comp.std.c++: considering