IBM researchers have developed Masking Gateway for Enterprises (MAGEN), software that uses optical character recognition and screen scraping technology to identify and conceal confidential information. IBM says MAGEN can prevent data leakage and allow for data sharing while protecting sensitive business data. MAGEN works at the screen level by "catching" the information before it reaches the screen, analyzing the content, and masking sensitive details that should be hidden from the potential viewer. The system treats the information as a picture, uses optical character recognition to identify confidential sections, and places a data "mask" over those details, without copying, changing, or processing the data. IBM says customers can set masking rules that can be defined per screen structure or per application. MAGEN does not change the software program or data, but rather filters information before it reaches the screen. The software also does not force companies to create modified copies of electronic records to mask, scramble, or eliminate data. IBM says MAGEN could be used for healthcare firms that outsource customer service and claims processing functions to a third party, enabling customer service representatives to access patient records while protecting private medical information.
Wednesday, July 15, 2009
Software to unlock the power of grids
A huge amount of computing power sits idle most of the time, and new technologies enabling the sharing of resources aim to capitalise on that. Now European researchers have developed software to simultaneously run applications on very different IT infrastructures.
Unlocking the power of grid computing has become one of the top priorities in the IT world. Optimising the use of existing resources rather than deploying new infrastructure is becoming increasingly important in the current economic climate.
At the same time, applications are taking longer to execute using traditional computing methods, with the amount of data being processed increasing at a rapid pace. This presents a problem because processing power is not keeping up with demand.
Moore’s Law predicted that the processing power of integrated circuits, or chips, would roughly double every 18 months. This has held true from the late 1950s until recently – the exponential growth has finally slowed down as the miniaturisation of components is nearing its limit.
An EU-funded project, GridCOMP, has been working around this conundrum by developing some clever software and middleware which allows applications to run on several, or even many, computers at the same time regardless of different infrastructures and architectures.
Full article : http://cordis.europa.eu/ictresults/index.cfm?section=news&tpl=article&BrowsingType=Features&ID=90738
Tuesday, July 14, 2009
DSL Line Attenuation/Noise Margin Explained.
Noise Margin (AKA Signal to Noise Margin or Signal to Noise Ratio)
Relative strength of the DSL signal to Noise ratio. The higher the number the better for this measurement. In some instances interleaving can help raise the noise margin to an acceptable level.
6dB or below is bad and will experience no synch or intermittent synch problems
7dB-10dB is fair but does not leave much room for variances in conditions
11dB-20dB is good with little or no synch problems* (but see note below)
20dB-28dB is excellent
29dB or above is outstanding
* Note that there may be short term bursts of noise that may drop the margin, but due to the sampling time of the management utility in your modem, will not show up in the figures.
Line Attenuation
Measure of how much the signal has degraded between the DSLAM and the modem. This is largely a function of the distance from the exchange. The lower the dB the better for this measurement.
20dB and below is outstanding
20dB-30dB is excellent
30dB-40dB is very good
40dB-50dB is good
50dB-60dB is poor and may experience connectivity issues
60dB or above is bad and will experience connectivity issues
DSL Rate ***/tx/rx/Rate
The actual service data rate that your ISP has provisioned.
Attainable Line Rate
This is the maximum rate at which your modem can connect to the DSLAM if there was no service provisioning limiting the bandwidth. The higher the number the better.
Occupancy
Occupancy is the percentage of line capacity used. Each DSL line is capable of a certain maximum speed or "capacity" dependant on line distance and other varying factors. The occupancy is an expression of your current sync rate setting over your maximum capacity. There are occupancy rates for both upload and download. The lower the figure, the better. Because of error correction and other factors in the DSL protocols, a margin is required so that a connection can be maintained under varying line conditions. If the occupancy approaches 100%, any interference can cause the ADSL sync to be lost. A useful measurement to monitor when sync problems occur. [AFAIK the billion SNMP utility does not give a direct measurement of occupancy :-( ]
(with due acknowledgment of the other sources/forums that this info was gleaned from)
Relative strength of the DSL signal to Noise ratio. The higher the number the better for this measurement. In some instances interleaving can help raise the noise margin to an acceptable level.
6dB or below is bad and will experience no synch or intermittent synch problems
7dB-10dB is fair but does not leave much room for variances in conditions
11dB-20dB is good with little or no synch problems* (but see note below)
20dB-28dB is excellent
29dB or above is outstanding
* Note that there may be short term bursts of noise that may drop the margin, but due to the sampling time of the management utility in your modem, will not show up in the figures.
Line Attenuation
Measure of how much the signal has degraded between the DSLAM and the modem. This is largely a function of the distance from the exchange. The lower the dB the better for this measurement.
20dB and below is outstanding
20dB-30dB is excellent
30dB-40dB is very good
40dB-50dB is good
50dB-60dB is poor and may experience connectivity issues
60dB or above is bad and will experience connectivity issues
DSL Rate ***/tx/rx/Rate
The actual service data rate that your ISP has provisioned.
Attainable Line Rate
This is the maximum rate at which your modem can connect to the DSLAM if there was no service provisioning limiting the bandwidth. The higher the number the better.
Occupancy
Occupancy is the percentage of line capacity used. Each DSL line is capable of a certain maximum speed or "capacity" dependant on line distance and other varying factors. The occupancy is an expression of your current sync rate setting over your maximum capacity. There are occupancy rates for both upload and download. The lower the figure, the better. Because of error correction and other factors in the DSL protocols, a margin is required so that a connection can be maintained under varying line conditions. If the occupancy approaches 100%, any interference can cause the ADSL sync to be lost. A useful measurement to monitor when sync problems occur. [AFAIK the billion SNMP utility does not give a direct measurement of occupancy :-( ]
(with due acknowledgment of the other sources/forums that this info was gleaned from)
Source : http://forums.whirlpool.net.au/forum-replies-archive.cfm/388705.html
Thursday, July 9, 2009
Browser : Google Chrome 3.0.192.0 is faster than Safari 4.0.2 (5530.19)
I'm using SunSpider Java Benchmark (http://www2.webkit.org/perf/sunspider-0.9/sunspider.html) for this testing. The result shows that Google Chrome (total run time : 903.0 ms) is faster than Safari (total run time : 1151.0ms) in most area of testing, but in some areas Chrome is also much slower. Chrome is slower in bitops, date and string maniplation.
For example :
1.60x as fast means Chrome is faster than Safari about 60% in 3d testing--3d cude (79% faster)
and 3d morph (90% faster).
TEST COMPARISON FROM TO DETAILS
=============================================================================
** TOTAL **: - 1151.0ms +/- 36.3% 903.0ms +/- 6.4%
=============================================================================
3d: 1.60x as fast 220.0ms +/- 18.8% 137.6ms +/- 13.1% significant
cube: 1.79x as fast 89.0ms +/- 25.8% 49.6ms +/- 4.2% significant
morph: 1.90x as fast 81.2ms +/- 25.6% 42.8ms +/- 31.4% significant
raytrace: - 49.8ms +/- 13.5% 45.2ms +/- 14.5%
access: 1.50x as fast 110.8ms +/- 4.4% 74.0ms +/- 8.3% significant
binary-trees: 2.00x as fast 10.0ms +/- 12.4% 5.0ms +/- 0.0% significant
fannkuch: ?? 28.4ms +/- 11.8% 29.0ms +/- 15.8% not conclusive: might be *1.02x as slow*
nbody: 1.71x as fast 55.2ms +/- 4.9% 32.2ms +/- 11.7% significant
nsieve: 2.21x as fast 17.2ms +/- 18.7% 7.8ms +/- 13.3% significant
bitops: *1.21x as slow* 58.0ms +/- 5.3% 70.4ms +/- 12.1% significant
3bit-bits-in-byte: 1.23x as fast 7.4ms +/- 9.2% 6.0ms +/- 29.3% significant
bits-in-byte: ?? 12.6ms +/- 11.3% 13.2ms +/- 25.3% not conclusive: might be *1.05x as slow*
bitwise-and: *2.82x as slow* 7.8ms +/- 17.5% 22.0ms +/- 9.8% significant
nsieve-bits: - 30.2ms +/- 7.4% 29.2ms +/- 18.9%
controlflow: 1.27x as fast 6.6ms +/- 10.3% 5.2ms +/- 20.0% significant
recursive: 1.27x as fast 6.6ms +/- 10.3% 5.2ms +/- 20.0% significant
crypto: 1.29x as fast 78.6ms +/- 8.1% 61.0ms +/- 12.8% significant
aes: ?? 23.8ms +/- 6.8% 25.8ms +/- 23.2% not conclusive: might be *1.08x as slow*
md5: 1.43x as fast 28.0ms +/- 9.9% 19.6ms +/- 16.5% significant
sha1: 1.72x as fast 26.8ms +/- 12.0% 15.6ms +/- 15.5% significant
date: *1.19x as slow* 96.2ms +/- 2.3% 114.2ms +/- 10.5% significant
format-tofte: *1.39x as slow* 45.0ms +/- 2.0% 62.4ms +/- 4.1% significant
format-xparb: ?? 51.2ms +/- 3.2% 51.8ms +/- 19.4% not conclusive: might be *1.01x as slow*
math: 1.57x as fast 129.0ms +/- 5.1% 82.0ms +/- 10.7% significant
cordic: 1.59x as fast 51.6ms +/- 8.1% 32.4ms +/- 15.7% significant
partial-sums: 1.51x as fast 52.4ms +/- 7.6% 34.8ms +/- 18.5% significant
spectral-norm: 1.69x as fast 25.0ms +/- 6.1% 14.8ms +/- 9.2% significant
regexp: 1.34x as fast 36.4ms +/- 5.2% 27.2ms +/- 3.8% significant
dna: 1.34x as fast 36.4ms +/- 5.2% 27.2ms +/- 3.8% significant
string: - 415.4ms +/- 92.0% 331.4ms +/- 3.8%
base64: - 171.2ms +/- 224.8% 42.8ms +/- 11.7%
fasta: 1.05x as fast 52.0ms +/- 2.4% 49.4ms +/- 10.5% significant
tagcloud: *1.26x as slow* 56.0ms +/- 6.3% 70.8ms +/- 6.5% significant
unpack-code: *1.20x as slow* 80.6ms +/- 6.2% 96.4ms +/- 3.7% significant
validate-input: *1.29x as slow* 55.6ms +/- 8.6% 72.0ms +/- 10.0% significant
Subscribe to:
Posts (Atom)
Posts
